Why 100% Code Coverage Can Still Miss a Bug
Code coverage measures which parts of a program ran while tests were running. A 100% line-coverage score means every executable line was reached at least once. It does not show that the tests checked whether those lines produced the right result.
Imagine a function that calculates a discount. A test might call it with a customer who qualifies, causing every line—including the discount calculation—to run. If the calculation mistakenly subtracts 20% instead of 10%, the test can still pass if it checks only that the function returned a number rather than verifying the correct price.
Execution Is Not the Same as Verification
A test needs an expectation: a statement about what the program should do. The test compares the program’s actual result with that expectation. If the expectation is missing, too vague, or itself based on the same mistaken assumption as the code, the test may confirm that the program ran without detecting faulty behavior.
Coverage also depends on what paths the tests take. Reaching every line does not necessarily mean testing every meaningful combination of conditions. A line might run for a normal input but fail for an empty value, a boundary case, or an unusual sequence of events. Even branch coverage—which tracks whether both outcomes of a decision ran—cannot establish that the expected outcomes were correct.
What a Coverage Score Can—and Cannot—Tell You
Coverage is useful for finding untested areas. A low score can point developers toward code that no test has exercised. A high score shows broad execution, but it is not a certificate of correctness. Stronger tests check specific outcomes, include edge cases, and challenge assumptions about how the program should behave.
That distinction matters most when a bug hides inside a line that tests already run: the code can be thoroughly visited and still quietly calculate the wrong answer.
