Engineering & Reliability

Code Coverage

VP Engineering Director Engineering CTO

Code Coverage measures the percentage of application code executed by automated tests in the test suite. It indicates how comprehensively the codebase is tested and is used as a proxy for the risk of undetected bugs reaching production. Line coverage, branch coverage, and path coverage are progressively more rigorous forms of the metric.

Code coverage percentage is a necessary but not sufficient quality indicator; 80% coverage with poorly written tests is less valuable than 60% coverage with tests that verify critical business logic under realistic conditions.

Formula

Lines (or Branches) Executed by Tests ÷ Total Lines (or Branches) × 100

Where It Lives

CodecovCoverage tracking, PR checks, and coverage trend reporting
SonarQubeCode coverage with quality gate enforcement
Istanbul / NYCJavaScript/TypeScript code coverage instrumentation
JaCoCoJava code coverage measurement in CI pipelines

What Drives It

Engineering culture and team standards for test quality
PR review requirements enforcing test coverage minimums
Coverage gate enforcement in CI/CD pipeline
Legacy code debt with limited test coverage
Time pressure on feature delivery crowding out test writing

Benchmark

Industry standard targets are 70%–80% line coverage; critical business logic and payment flows often warrant 90%+; legacy systems may realistically operate at 40%–60%.

Common Questions About Code Coverage

What is the difference between line coverage, branch coverage, and path coverage?

Line coverage measures which lines of code are executed by tests. Branch coverage measures whether both the true and false outcomes of each conditional statement are tested. Path coverage measures all unique execution paths through the code. Each is more rigorous than the previous: 100% line coverage can miss untested else branches; 100% branch coverage can miss complex multi-condition paths. For critical systems, branch coverage is the practical target.

Is 100% code coverage a good goal?

Not always. Achieving the final 10%–20% of coverage often requires disproportionate effort testing boilerplate, error handling, and edge cases that rarely occur in production. The ROI of test effort is highest in the 60%–80% coverage range where most critical logic is covered. Above 80%, invest in coverage quality (assertion depth, realistic test data) rather than purely maximizing the percentage.

How should I increase code coverage in a legacy codebase?

Start by identifying the highest-risk areas: code paths involved in recent production incidents, core business logic, and payment or security-critical flows. Prioritize coverage in these areas first. Use mutation testing to validate that existing tests are actually catching bugs. Add tests incrementally as code is modified (the "boy scout rule": leave coverage better than you found it). Avoid the big-bang approach of trying to cover the entire legacy codebase at once.

What is mutation testing and how does it improve coverage quality?

Mutation testing automatically introduces small bugs (mutations) into the source code and runs the test suite to see if any tests fail. If a mutation survives (no test catches it), it indicates the test suite does not adequately verify that code. Mutation testing reveals whether tests are actually asserting meaningful behavior or just executing code to inflate coverage. Tools like Pitest (Java) and StrykerJS (JavaScript) implement mutation testing.

Related Metrics

CFR | Change Failure Rate Deployment Frequency | Deployment Frequency Technical Debt Ratio | Technical Debt Ratio Error Rate | Error Rate

free, one business day

Want to know what is holding your Code Coverage back?

Give us your website and we will send back the specific pages hurting your Code Coverage, in the order worth fixing. You will have it within one business day, free, with no obligation.