Code Coverage: What Your Tests Don't Tell You

WHY IT EXISTS Software development needs a way to answer the question, "How much of our code are we even running during tests?" Without a systematic measure, teams are blind to which parts of an application have never been executed by their test suite, leaving bugs hidden in untested corners.

THE MENTAL MODEL Think of code coverage like a map of a city where you've only driven on certain streets. The coverage report shows you which streets (lines of code) you've driven down, but it doesn't tell you if you checked for potholes (made good assertions) or just drove through. Its real value is revealing the unexplored parts of your codebase.

HOW IT WORKS Coverage tools instrument your code, adding trackers to each line, branch, or function. When you run your test suite, these trackers record which parts of the code are executed. The tool then generates a report, typically a percentage of executed code versus total code. Common metrics include statement coverage (lines executed) and function coverage (functions called).

WHEN TO USE IT Use it as a diagnostic tool to find untested code. It's valuable in CI pipelines to set a baseline and prevent coverage from decreasing over time (a practice called a coverage ratchet). It helps guide developers to write tests for critical but overlooked logic.

WHEN NOT TO USE IT Do not use it as the primary goal or a direct measure of software quality. Chasing a 100% coverage target often leads to low-value tests that check trivial code but don't make meaningful assertions. This creates a maintenance burden for no real benefit and fosters a false sense of security.

ONE CANONICAL EXAMPLE A test suite runs against a program and a coverage tool reports "85% statement coverage." This means that when all tests were executed, 85 out of every 100 lines of executable code were run at least once. The remaining 15% of the code was never touched by any test, representing a clear blind spot.