I'm pretty new to TDD approach and my first experiments say that writing 1 line of functional code means writing about 2-3 lines of testing code. So, in case I'm going to write 1000 LOC, the whole codebase including tests is going to be something like ~3500 LOC.

Is this considered normal? What is the ratio in code you write?

  • 8
    Yeap, TDD comes with a pricey tag !
    – Yusubov
    Commented Jul 15, 2012 at 10:21
  • 6
    your 2-3X number is conservative at best, it is actually closer to 4-5X for things like C#/Java, Python/Ruby might be closer to 2-3X, with something terse like Erlang being closer to 1:1. Depends on how dogmatic you are about TDD, the more dogmatic, the bigger those ratios get!
    – user7519
    Commented Jul 15, 2012 at 10:35
  • 6
    @tomwrong: In Kent's book he cites Ward that you should write tests until your fear transforms into boredom.
    – herby
    Commented Jul 15, 2012 at 10:54
  • 4
    @ElYusubov: I don't agree that it's "pricey" at all. It seems so for those who still count amount of work in LOCs. But the price is not in LOC, it is in money and time-to-market. And there, TDD is not more pricey than any other reasonable development process.
    – herby
    Commented Jul 15, 2012 at 10:58
  • 5
    Guys, why do you comment instead of posting answers? What you write makes sense. Commented Jul 15, 2012 at 11:00

6 Answers 6


1:3 is normal with TDD.

From my experience, and also from other citations I remember.

  • 14
    ...what citations?
    – TehShrike
    Commented Jul 15, 2012 at 12:34
  • ... vaguely remember ... I already don't remember where it was (maybe in the Kent Beck's TDD By Example, maybe in somewhere in c2.com). I remember the meaning, though, that three times more test code than production code is ok.
    – herby
    Commented Jul 15, 2012 at 12:36
  • Wow, exactly the same in my experience, too. (I am staring at results from cloc right now and I searched google to find any posts on this ratio) Commented Apr 12, 2014 at 10:56

There are variations based on different coding styles and languages. However, regardless of the language you use, the biggest variation is you.

Robert Martin once said:

“As the tests get more specific, the code gets more generic.”

That made me think. More specific tests mean more test code. More generic production code means less code, so test/code ratios should rise as the code evolves.

But wait, that's not good either. In some particular cases, for example when you define a certain algorithm, you may have only 6-10 lines of code containing a couple of "if"s, a while and maybe 2-3 recursions. I can tell you, that code will have probably more 100 lines of test code.

In a real project, something bigger than just a few algorithms, the test/code ratio should be somewhere between 1:1 and 2:1. If it gets above 2:1, it's a smell that you have tests that should be refactored or deleted (or maybe code that is hard to test). You should always invest the same amount of care and refactoring in your tests as in your production code.

Any way, the best answer to your question maybe is "Cyclomatic Complexity". The higher the cyclomatic complexity of your method, the exponentially more test you have to write for it to cover all the cases.

  • The quote you mentioned describes a thing called Test Contra-Variance. Uncle Bob discusses it in further detail in the blog post I've linked.
    – byxor
    Commented Feb 4, 2020 at 15:14

The ratio is going to vary depending on the size of your methods. The size of your methods will vary by programming style, language and problem domain.

If your methods are short then 3:1 is reasonable. If your methods are long then 3:1 is on the high side.

So, to answer your question, it depends. :-)

  • It depends on what you mean by "methods are long". What image it created in my head, is that methods are unnecessary long, doing too much work and having too much responsibilities (often having too many parameters). In that case, such method needs proportionally more combinations to cover by tests, so I don't think the ratio would change much...
    – herby
    Commented Jul 15, 2012 at 15:50
  • Assume for a moment you can set up a test, call the method to be tested and check the result in three lines of code. If the method you are testing is one line long (as happens in Scala) then your test to production code ration is 3:1. If the method is six lines long then it's 1:2. Six lines isn't all that long. Commented Jul 16, 2012 at 16:02

For software critical application, the usual ratio is one day of testing for each 10 functional LoC.

And this is not counting TDD which is not about test but about specification.


The size of my test code is about half of what the 'actual' code is overall. Doing otherwise is indicative that your tests are too complex and/or your code is too hard to test and/or your code is too dense/complex.

Or you're simply testing too much, and wasting your time on diminishing returns.

Also see "when is unit testing inappropriate or unnecessary?"


My ratio is around 2-1 to 10-1 (code to test). Make sure you testing is about value/behaviour and not implementation.

Not the answer you're looking for? Browse other questions tagged or ask your own question.