Being honest about code coverage

| RSS | Edit on GitHub | Read more of my posts

In my experience, discussing code coverage has always been done with an expectation of a binary conclusion; it’s either a good metric to shoot for or it isn’t. It seems to me like there’s more to be gained if the question is framed differently: how does one achieve high code coverage beneficially?

Asking it this way leads to more fruitful argumentation because the following points are no longer part of the question:

To those arguments, my answer is: the problem is not code coverage, but code that’s hard to test, a dogmatic approach to unit testing leading to their misuse, or the very fact that one often tries to increase code coverage by writing more tests.

So, as an exercise, let’s agree on this for the next couple of paragraphs: code coverage is a good metric as long as you’re honest about how to increase it.

What does it mean to be honest about increasing coverage?

Code coverage can bear a lot of meaning or very little. If you decide to track it, you and your peers will face having to decide whether to be diligent about it or not, and I’d say that’s a good thing.