Few metrics are chased as devotedly — and misleadingly — as test coverage. The number is easy to measure, easy to report and easy to mistake for quality. But coverage measures what your tests touch, not what they verify.
Why the number lies
Not all coverage is created equal. A test can execute every line of a function without asserting anything meaningful about its behaviour — a checked-off grocery list with cracked eggs in the bag. I have seen a team reach 100% coverage and still ship bugs, because their tests never validated real-world scenarios.
High numbers also create false security. A suite at 95% can still miss a critical security bug if the tests are shallow — a fancy alarm system with the front door wide open. The depth of tests matters more than the percentage they produce.
The cost of the last few percent
Coverage has sharply diminishing returns. The closer you get to 100%, the harder and costlier each additional line becomes — squeezing the last drop from an empty toothpaste tube. Full coverage often means writing convoluted test setups for the most complex, least valuable corners of the codebase, and every one of those tests must then be maintained. Tightly coupled tests break on every small change, and the suite itself becomes a drag on the system it was supposed to protect.
What to aim for instead
Focus on effective coverage, not perfect coverage: critical paths, edge cases and high-risk areas. The goal is reliability, not a number.
The teams I have seen do this well share a few habits. They leave genuinely low-risk code uncovered and spend that effort where failures hurt — and end up with fewer bugs and a codebase that is easier to maintain. They simplify complex modules to make them testable instead of writing complex tests for complex code. And they keep the suite lean: meaningful tests that validate core functionality, no over-testing of trivial code.
The quality of your tests matters more than the quantity of your coverage. When someone asks why the dashboard doesn't show 100%, the honest answer is that 100% was never the goal — working software was.