What a coverage percentage actually measures
Code coverage records which parts of a program ran while tests were executing. A line-coverage tool, for example, can report that a test touched nearly every line of code. That is useful as a map of untested areas—but it cannot tell whether a test would notice the program producing the wrong result.
A test can call a function and discard its answer, or run a line without checking what it changed. The line is counted as covered even though the test has no meaningful expectation to fail if the behavior breaks. Coverage answers “Did this code run?” not “Would we catch a mistake here?”
How the metric becomes the mission
The trouble starts when a target—say, raising coverage before a release—becomes a pass-or-fail requirement. A developer under pressure can add tests that execute uncovered code with minimal assertions, quickly improving the reported number. The dashboard turns green, but the tests may leave the important question untouched: does the feature behave correctly when inputs or conditions change?
This creates false confidence. Teams may spend time maintaining tests that contribute little protection, while reviewers and managers mistake a high percentage for evidence of reliability. Worse, a test that merely repeats the code’s current behavior can make a later correction harder: changing the behavior causes the test to fail, even when the change is intentional.
Use coverage as a map, not a verdict
A stronger test checks an observable outcome: for instance, that a rejected payment leaves an order unpaid, or that a boundary input produces the intended result. Coverage can then help point to code with no such tests, while human judgment decides which untested paths matter most.
The useful signal is not a chart that is green by itself. It is a test that would turn red when a consequential behavior goes wrong—and gives the team enough information to find out why.
