Test Coverage

What Is Test Coverage?

Test coverage is a quantitative metric that measures how much of a codebase is exercised when automated tests run. It is typically expressed as a percentage: 80% test coverage means that 80% of the code was executed during the test suite, while 20% was never reached by any test.

Test coverage encompasses several sub-metrics, including line coverage (what percentage of lines were executed), branch coverage (what percentage of conditional branches were taken), function coverage (what percentage of functions were called), and statement coverage. Each metric provides a different perspective on how thoroughly the code is tested.

The term “test coverage” is sometimes used interchangeably with “code coverage,” but there is a subtle distinction. Code coverage is a pure measurement of which code was executed during testing. Test coverage is a broader concept that considers not just whether code was executed, but whether the tests are actually verifying the correct behavior. A function can be fully covered by code execution without a single meaningful assertion — the code ran, but nothing was validated. True test coverage considers the quality and intent of assertions, not just execution paths.

How It Works

Coverage tools instrument the source code to track which lines, branches, and functions are executed during test runs. After the tests complete, the tool generates a report showing covered and uncovered code.

In JavaScript with Jest, coverage is built in:

npx jest --coverage

This produces output like:

------------------|---------|----------|---------|---------|
File              | % Stmts | % Branch | % Funcs | % Lines |
------------------|---------|----------|---------|---------|
All files         |   87.23 |    72.41 |   91.67 |   88.10 |
 cart.js          |   100   |    100   |   100   |   100   |
 checkout.js      |   76.47 |    50    |   83.33 |   78.57 |
 payment.js       |   84.21 |    66.67 |   100   |   84.62 |
------------------|---------|----------|---------|---------|

In Python, you use the coverage package with pytest:

pip install coverage
coverage run -m pytest
coverage report -m

Name                    Stmts   Miss  Cover   Missing
-----------------------------------------------------
cart.py                    28      0   100%
checkout.py                34      8    76%   45-52
payment.py                 19      3    84%   22, 35-36
-----------------------------------------------------
TOTAL                      81     11    86%

The Missing column shows exact line numbers that were never executed, guiding developers to write additional tests for uncovered code. Many teams integrate coverage reporting into their CI pipelines and set minimum thresholds:

# jest.config.js
module.exports = {
  coverageThreshold: {
    global: {
      branches: 70,
      functions: 80,
      lines: 80,
      statements: 80,
    },
  },
};

If coverage drops below the configured threshold, the CI build fails, preventing merges that reduce test coverage.

Why It Matters

Test coverage provides an objective, measurable signal about testing gaps. Without coverage data, teams rely on intuition to decide whether their tests are sufficient. With coverage data, they can identify exactly which functions, branches, and error paths lack tests and prioritize their testing efforts accordingly.

Coverage is particularly valuable during code review. When a developer submits a pull request, a coverage report can show whether the new code includes tests. Reviewers can quickly spot untested error handling, uncovered edge cases, or entirely untested functions without manually inspecting every test file.

Coverage metrics also serve as a baseline for code health. A codebase that consistently maintains 80% coverage is more maintainable than one with 30% coverage because developers can refactor and extend it with higher confidence that regressions will be caught. Over time, coverage trends — whether coverage is increasing or decreasing with each release — provide insight into whether the team’s testing discipline is improving or degrading.

Best Practices

• Set a coverage floor, not a ceiling. Require that coverage never drops below a defined minimum (e.g., 80% line coverage) rather than demanding 100%. A coverage floor prevents regressions in testing discipline without creating perverse incentives.
• Focus coverage on critical code. Business logic, security-sensitive functions, and error handling paths deserve high coverage. Configuration files, generated code, and simple data transfer objects do not.
• Track coverage trends over time. A single coverage number is less informative than the trend. A codebase at 75% and climbing is healthier than one at 85% and falling.
• Use coverage to find gaps, not to prove quality. High coverage does not mean the tests are good — it means the code was executed. Use coverage reports to identify untested code and then write meaningful tests with thoughtful assertions.
• Enforce coverage on new code. Even if the legacy codebase has low overall coverage, require that every new pull request maintains or improves coverage. This ratchets coverage upward over time.

Common Mistakes

• Chasing 100% coverage. Achieving 100% coverage requires testing trivial getters, defensive code paths that cannot realistically be triggered, and framework-generated boilerplate. The effort required to go from 90% to 100% is disproportionate to the value gained, and the resulting tests are often brittle and meaningless.
• Writing tests without assertions to boost coverage. Calling a function in a test without asserting anything exercises the code and increases the coverage percentage, but it does not actually test anything. These phantom tests create a false sense of security.
• Using coverage as the sole quality metric. Coverage tells you what code was executed, not whether the tests are correct or comprehensive. A test suite with 95% coverage can still miss critical bugs if it lacks assertions on edge cases, error conditions, and boundary values.
• Ignoring branch coverage. A function with an if-else block can show 100% line coverage if both branches are on single lines and one branch is tested. Branch coverage reveals that only half the logic paths were exercised, which is a more meaningful gap.