Skip to content

100% code coverage

by Alex Peck on September 25th, 2009

Unit tests can’t expose bugs in code they don’t execute. Therefore, unit tests should have a high degree of code coverage. If you test first, inject all dependencies and use mocks, 100% block coverage isn’t an onerous a goal. But what does block coverage really tell you?

The answer is not much. It’s easy to spot which code you didn’t execute. For code that did execute, if neither the behaviour nor resultant state is verified, all you really know is that there were no unexpected errors. In other words, this code coverage is merely incidental, and no actual testing took place.

Furthermore, even with 100% coverage you have no indication of the code you should have written, but didn’t. For example, consider this simple one liner:

public float Divide(float dividend, float divisor)
{
   return dividend / divisor;
}
 
public void TestDivide()
{
   float quotient = Divide(10, 2);
   Assert.AreEqual<float>(5, quotient);
}

The test case gives us 100% block coverage. However, we will get different behaviour if we use a divisor of 0. This different behaviour may very well constitute a bug. Interestingly, we won’t find this bug even if we use a more robust coverage metric (e.g path coverage) because it is a boundary problem.

No comments yet

Leave a Reply

Note: XHTML is allowed. Your email address will never be published.

Subscribe to this comment feed via RSS