Ditch code coverage
TLDR;
It's often misused and it doesn't offer any real benefits, ditch it.
What is code coverage?
Commonly code coverage refers to the number of lines of your code that is covered by tests, most commonly unit tests. This could also refer to integration tests, depending on how loose the definitions are for tests that you're working with.
Most of the tools out there are pretty self explanatory they essentially measure what percentage of lines, branches, functions and statements are covered by tests that you've written. This is often paired with some sort of CI or pre commit check that prevents you from lowering the code coverage in particular areas, and this is where the problem starts.
Why you shouldn't use it
For starters it isn't accurate, let's take a look at the very rough code examples below that show how it may not tell the truth about the coverage of your code.
The first example is just a simple module that exports a very simple add two numbers func and the same thing in reverse for fun
The code snippet has been ommited on mobile, for your sanity and mine 🤝. You could turn the phone sideways if you want some context 🤷.
An accompanying test might look like
The code snippet has been ommited on mobile, for your sanity and mine 🤝. You could turn the phone sideways if you want some context 🤷.
And the coverage for this looks like this (using jest)
The code snippet has been ommited on mobile, for your sanity and mine 🤝. You could turn the phone sideways if you want some context 🤷.
You may have noticed that there's a bug in our code, one that our current tests don't catch. So let's create a new file and fix that code, write some a test that covers it and maybe refactor the reverse function a little bit as well so it is easier to read.
The code snippet has been ommited on mobile, for your sanity and mine 🤝. You could turn the phone sideways if you want some context 🤷.
And then we update the tests...
The code snippet has been ommited on mobile, for your sanity and mine 🤝. You could turn the phone sideways if you want some context 🤷.
But now we've got way less coverage! Even though this code is less buggy and actually covered by more tests than the previous one.
The code snippet has been ommited on mobile, for your sanity and mine 🤝. You could turn the phone sideways if you want some context 🤷.
When you report code coverage and introduce thresholds you will inevitably end up writing tests for things that shouldn't have tests in the first place and perhaps even end up writing tests for elements that weren't related to your changes. This can make code reviews a lot messier and introduce extra unforeseen work.
Higher code coverage doesn't mean less bugs. There's nothing that suggests that the higher your code coverage, the less bugs you have a result. In fact, higher fidelity tests are the only thing that result in less bugs, but usually the higher fidelity test code coverage reports are very difficult and definitely impractical to generate.