Code coverage

Code coverage is a measurement taken by instrumenting the code, running the suite, and recording which lines, branches or functions were reached. A line that executed counts as covered, and that is the entire claim the number makes. It says nothing about whether an assertion was made about what happened on that line, whether the behaviour was correct, or whether the case that would have mattered was among the ones exercised.

Teams reach for coverage because it is the one quality figure that arrives free with the tooling and compresses into a single number a stakeholder can read. That convenience is also the trap. Once a percentage becomes a target it stops being a measurement, and the cheapest way to move it is to write tests that run code without checking anything about the result. We use coverage to find the places nobody has looked at, and never as evidence that the covered part works.

What the measurement is genuinely good for

• Finding untouched regions. A module reporting zero is a real finding, and it is usually either dead code or the risky area everyone has been avoiding.
• Reviewing the delta on a change. Coverage of the lines a pull request adds is a fair question to ask an author; coverage across a codebase built over years is a number about its history.
• Separating line coverage from branch coverage. Line counting marks a conditional as covered when only one side of it ran, which is how a suite reports a healthy figure while never once testing a failure path.
• Arguing about risk with something concrete in front of you. Agreeing where to spend testing effort is easier when both sides are looking at the same map of what has never been executed.

A suite can execute every line in a module while asserting nothing about the results, which is why a high coverage figure and a well-tested system are two different claims.