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

• Anonymous
  November 05, 2003
  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.
• Anonymous
  November 06, 2003
  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.