I have read a great many things questioning the value of the measurement of test coverage. I believe that there is a common misconception about test coverage and what our coverage numbers can tell us about our code.
The common criticisms are that while the coverage report can tell us how much of the code has been exercised it does not tell us how well. This is absolutely true. High coverage numbers are no substitute for reading the code (and the tests) and understanding what it supposed to do. What the coverage numbers can give us is a measure of testability.
If you need to make changes to a piece of code that has very high test coverage you can plan that work with the confidence that the code is designed in a way that will not make it incredibly difficult to change. This typically means that it adheres good design principles like Single Responsibility and Inversion of Control. Furthermore it means you will have some tests to look at along with the code you are trying to understand before you change it. Even if the quality of those tests is not enough to give you the confidence you need to change the code, you will already have the starting point you need to add better tests. It’s much easier to change incomplete tests into good tests than it is to change no tests into good tests.
Perhaps instead of test coverage we should call it testability coverage.
Lazy Initialization :: Creating Better Mock Tests With Hamcrest Custom Matchers | 08-Aug-08 at 6:38 pm | Permalink
[...] these techniques regularly can help move 100% coverage away from a nearly impossible (and questionably valuable) goal and much closer to a milestone achievable with an extra bit of incremental [...]