Field Guide to Programmers

In simple terms, code coverage is the metric that tells you how much of your application’s source code is touched by the unit tests in your test suite. It is a core measurement of success in most test-driven methodologies.

There’s actually a lot more to it (as you can see in the referenced Wikipedia article). In general, code coverage is a good thing. But like all god things, it is possible to go a wee bit overboard, just ask Kyle…

Monitoring code coverage, or “How to descend into madness”:

It started innocently enough. We added code coverage statistics a while back but only lately have we broken the build when it dropped below a certain level. We started at 60% and last week, our coverage sat at 67%. So I upped the threshold to 65% and after some good-natured goading among the team, I raised it to 66%. Y’know, just as a joke. No harm, no foul, eh?

A couple of days later and the coverage is starting to hover near 70%. “Very exciting,” says I, “soon we’ll be able to increase the threshold to 70%”. And the excitement I felt at that notion should have been a tipoff to seek some form of counselling.

[via: CodeBetter.Com]

I tend to think that 65%+ is probably reaching maximum efficiency in code coverage. I know some folks try to shoot for 100%, but this seems excessive. Of course, my figure is based more on gut than on a deep quantitative analysis. Scott Sehlhorst has a very compelling and quantitative argument for at least 90% code coverage (5/2006).

I dig what Scott is saying, but then I don’t want to end up like Kyle…