Unit Test Code Coverage - What Is A Good Number?

Shawn writes that you should have 100% test code coverage, Jason agrees. Tokes, a co-worker and the person who pointed these posts out to me, disagrees.

I also disagree.

Background

I'm a strong believer in unit testing. I have used unit testing in almost every project I have been involved in for a couple of years now and each time I find I get more and more value from using them.

My experience with code coverage tools is more limited. I first started looking at NCover and code coverage after coming across an NCover article written its creator. The article used Json.NET, my own open source project, as the example! (if that doesn't prompt you to look at something nothing will [:D])

 I'll keep it short and sweet -- Family. Religion. Friendship. These are the three demons you must slay if you wish to succeed in business.

Near the end of the development cycle of Json.NET 2.0 NCover was of huge help identifying which methods and sections of code didn't have any tests running over them. Without NCover many of the bugs I found from eventually unit testing that code would still be in Json.NET.

Coverage Percentage

While I think NCover is a great tool to identify what sections of code aren't being tested, the overall percentage mark that it gives is potentially dangerous.

Every software project has limited resources and spending your time chasing that number is a poor use of it. 100% coverage certainly doesn't mean that your program is bug free. Code that works with one input will break with another.

When it comes to unit testing I believe you are better off writing tests that focus on your use cases.

Obviously checking that the results are right is important but there is also making sure that your code behaves as expected when passed boundary values, performing inverse operations and cross checking results elsewhere in the application. These are all important things to test when creating robust code but aren't necessary to achieve 100% coverage.

A Good Number

So what is a good number? If you have written tests the cover the possible uses of your application given the time available (NCover is useful for double checking that you are testing everything you want to) and have then have verified that the results are correct, whatever number your code coverage is at that moment is in my opinion a good number.

Json.NET's was 85%

The results are in: for Sideshow Bob, one hundred percent; and for Joe Quimby, one percent. And we remind you there is a one percent margin of error.

kick it on DotNetKicks.com