Typical size of unit tests compared to test code

Question

I'm curious what a reasonable / typical value is for the ratio of test code to production code when people are doing TDD. Looking at one component, I have 530 lines of test code for 130 lines of production code. Another component has 1000 lines of test code for 360 lines of production code. So the unit tests are requiring roughly 3x to 5x as much code. This is for Javascript code. I don't have much tested C# code handy, but I think for another project I was looking at 2x to 3x as much test code then production code.

It would seem to me that the lower that value is, assuming the tests are sufficient, would reflect higher quality tests. Pure speculation, I just wonder what ratios other people see.

I know lines of code is an loose metric, but since I code in the same style for both test and production (same spacing format, same ammount of comments, etc) the values are comparable.

Answer 1

This will really depend on how well things are factored but, to my experience (yes, I did measure this on some projects), I've seen ratios from 2:1 to 5:1 (this is for tested code of course). Also have a look at the ProductionCodeVsUnitTestsRatio and UnitTestToCodeRatio pages on the C2 wiki.

Answer 2

Those numbers sound normal. The longest unit test I've written was more than 1500 lines and it only tested about 300 lines of code.

Answer 3

Wow, those numbers are quite large! I'm roughly 1:1, sometimes for classes which have a higher cyclomatic complexity it may go nearer 2:1 in favour of unit tests LOC, but then that sets off alarm bells that the class needs refactoring.

You mention that you are using the same style for your unit tests. That is good as far as treating your tests as production code, but do you really need lots of comments for test code? Are you naming your test methods so they are descriptive of what the test is asserting? for example using the 'GivenXWhenYThenZ' function naming, then it should be pretty clear what the test does without a large comments section.

Are you refactoring your tests? moving any duplication of setup etc into separate methods?

Are you keeping your unit tests simple so they only assert one thing per test?

and are you excessively testing things like getters/setters?

Answer 4

Different languages and testing frameworks will be very different. For example, BDD frameworks much "DRYer" than TestUnit style code. Also, on a couple projects I ended up having very large data sets fed through just a few lines of Java-- that tested thousands of lines of the code-- so my ratio would be all screwy.

I just looked at my three most recent projects (medium size rails), and the code to test ratios were 1:2.3, 1:1.6, and 1:1.9... so you numbers sound like they are similar. (I just ran rake stats-- I never really looked at them before.)

Anyway, warning signs that you have too many tests:

• if you make one change do multiple tests fail, or just one? If a large number of tests fails, you're probably testing the same thing over and over and can eliminate most of them.
• code looks like it was copy and pasted. Refactor out common code.
• tests are too slow
• tests that have never failed