Code coverages measures how much of your source code is executed while your tests run.
It can’t tell you if your code is correct or follows basic design principles.
It can’t tell you if your product supplies your customers’ needs.
It can’t tell you if your tests are any good.
You can write tests that don’t actually assert anything, and the lines of code executed while those tests are running will contribute to your code coverage number.
It is a very simple metric to calculate, and thus vendor tooling is easy to wrap around it.
If you practice test-driven development, and you only write code when a test pulls it into existence, you’re likely going to have a high code coverage percentage.
I wouldn’t chase code coverage as a metric. It’s only usefulness seems to be in letting you know when large portions of your system aren’t covered by tests. If you focus on good technical practice, code coverage will likely follow. But if you don’t hit 100%, I wouldn’t lose sleep over that.
