I’ve always been a huge believer in using Code Coverage tools (such as Clover, CodeCover, EMMA, gcov, etc) as a way to report on how in-depth your unit tests are.  Generally, I use them with Quality Assurance/Quality Control groups to determine where to focus any additional testing efforts during a Sprint.  While we tend to benchmark required coverage at 85%, this is always a general rule with the understanding that every project (and, therefore, every project’s code) is going to be different, with different needs.

An interesting post at InfoQ talks a bit about the need to be careful about using a required coverage metric during TDD:

Out of the gates, Gruber’s primary statement is that TDD proponents do not suggest code coverage as “a one true metric”, that it is useful but only to degree and taken in context with other sources of feedback. He denounces Pang’s claim that “(Pang) 100% code coverage has long been the ultimate goal of testing fanatics”, stating that “(Gruber) high code coverage is a desired attribute of a well tested system, but the goal is to have a fully and sufficiently tested system”.

I completely agree with this statement.  Code coverage is, again, a tool for determining where additional testing time can be spent, as well as identifying any risks of releasing code into production that is not currently covered by unit tests.

The following quote sums it up nicely:

code coverage [in the context of TDD] is a great way to notice that you screwed up and missed something, but nothing else

More information can be found on InfoQ’s post.

No related posts.