Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
6  
Yeap, TDD comes with a pricey tag ! –  Yusubov Jul 15 '12 at 10:21
2  
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! –  Jarrod Roberson Jul 15 '12 at 10:35
1  
You are hitting upon one of the most contentious issues in TDD. When is it overkill? (personally I dread writing test) –  tomwrong Jul 15 '12 at 10:41
2  
@tomwrong: In Kent's book he cites Ward that you should write tests until your fear transforms into boredom. –  herby Jul 15 '12 at 10:54
3  
@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 Jul 15 '12 at 10:58

5 Answers 5

up vote 8 down vote accepted

1:3 is normal with TDD.

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

share|improve this answer
7  
...what citations? –  TehShrike Jul 15 '12 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 Jul 15 '12 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) –  Nikolay Tsenkov Apr 12 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.

share|improve this answer

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. :-)

share|improve this answer
    
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 Jul 15 '12 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. –  Jon Strayer Jul 16 '12 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.

share|improve this answer

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?"

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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