Code coverage measures the percentage of a codebase exercised by its test suite — which lines, branches, or functions ran — a useful signal for finding untested code, but not a guarantee of correctness.1
What it measures
Coverage tools instrument the code and record which parts executed while the tests ran, reported as a percentage. Common granularities are line coverage (which lines ran), branch coverage (which sides of each conditional ran), and function coverage.1 The metric is genuinely useful for finding untested code: a module sitting at 0% is a red flag, and watching coverage shows where to aim the next tests. Coverage is typically computed in a CI/CD pipeline so the number is tracked on every change.
Its limits
Coverage is widely misread. It measures whether a line ran, not whether your test checked anything meaningful about it. You can reach 100% with tests that assert nothing, miss every edge case, or compare against wrong expected values — and heavy mocking can inflate the number without real assurance. High coverage with weak assertions is false confidence. Treat coverage as a floor — a signal for gaps — never as a target to chase or a proof of correctness. A smaller suite of sharp, well-asserted tests beats a sprawling one written to game a number.
In context
Coverage spans every layer of the test pyramid — unit, integration, and end-to-end tests all contribute. It is a by-product of disciplines like test-driven development, not their purpose, and it gives refactoring confidence by showing which code a change’s safety net actually protects.
Sources
-
Code coverage — Wikipedia, for the metric, its granularities (line, branch, function), and its limits. ↩ ↩2