Unit tests: How much is enough?

Looking back on some of my earlier projects, I noticed that  UTs account for roughly 20% of my total code lines.   I was wondering if anyone else has similar numbers for their unit tests?   It seems to me that my numbers are a bit low,  to achieve total test coverage I would expect over 50% (meaning more UT  code then project code). On the other hand, I have yet to come across an application which actually achieved that kind of testing completeness other than certain open source libraries.  

I know what the literature says,  now can anyone come up with some real world numbers to back up my theory?  

Comments (3)

  1. Alan Dean says:

    I use test-first development practices, so I am not allowed to write code unless a test has failed – and then only enough code to pass the test.

    • In my first iterations my tests are about 35% of the codebase.

    • In later iterations, this proportion tends to rise as more tests are written to describe more obscure cases, and as the core code is simplified by refactoring.

    • By the end of the main development, the proportion is up to around 50%.

    • During defect management (test-first doesn’t banish all defects) this proportion rises further as defects have to be described by tests before you are allowed to resolve them (which is a good way of enforcing the reproduction of defects) the proportion rises further.

    • In a fully mature codebase, I would expect up to 75% of the codebase to be tests.

  2. Yura2000 says:

    Hi Addy!

    In my oppinion this is not right approach – to count lines of code.

    Check what diffs in the development and QA time – before and after using NUnit.