What Is Code Coverage?

Code coverage metrics measure the percentage of a software codebase that is exercised by automated tests. Common types include line coverage, branch coverage, function coverage, and statement coverage, each quantifying a different aspect of how thoroughly tests validate the code. These metrics help teams identify untested areas that may harbor undetected defects.

Untested code is a liability. Google's engineering practices research found that modules with less than 60% code coverage experience defect rates two to three times higher than well-tested modules. When significant portions of a codebase lack test coverage, teams ship changes without confidence that existing functionality remains intact. That uncertainty slows down development, increases manual testing burden, and raises the probability of production incidents.

Code coverage metrics provide a quantitative answer to the question "how well tested is our code?" Without measurement, teams operate on assumptions. A developer might believe a critical service is well tested because it has a test file, but coverage data might reveal that the test file only exercises the happy path while leaving error handling and edge cases completely untested.

Coverage metrics also serve as a forcing function for testing discipline. When teams set minimum coverage thresholds for pull requests, they prevent new code from entering the codebase without adequate tests. Over time, this practice raises the overall code health baseline and reduces the volume of defects that reach production.

Code coverage tools instrument the source code during test execution, tracking which lines, branches, and functions are reached. After the test suite runs, the tool generates a report showing the percentage of each category that was exercised. Most tools also produce visual overlays that highlight covered and uncovered lines directly in the source code.

Branch coverage is generally considered more informative than line coverage. A conditional statement like an if/else block might show 100% line coverage if only the "if" path is tested, but branch coverage would correctly report 50% because the "else" path was never executed. Teams focused on thorough testing typically track branch coverage as their primary metric.

Setting coverage targets requires nuance. A blanket 100% target is usually counterproductive because it incentivizes writing low-value tests for trivial code like simple getters and configuration files. Most experienced teams aim for 70 to 80% overall coverage with higher thresholds, 90% or above, for critical business logic and shared libraries. Understanding how coverage interacts with code complexity helps teams focus testing effort where it matters most.

Every major programming language has established coverage tooling. Istanbul and Jest provide JavaScript and TypeScript coverage. Coverage.py handles Python projects. JaCoCo covers Java and Kotlin. Go includes built-in coverage support via the "go test" command. These tools integrate with CI/CD systems to enforce coverage thresholds on every pull request.

Aggregation platforms like Codecov and Coveralls collect coverage data across repositories and present trends over time. They flag pull requests that reduce overall coverage, helping teams maintain their testing baseline. Glue complements these tools by connecting coverage data to broader engineering health signals, showing teams how test coverage gaps correlate with defect rates, review cycle times, and code change frequency. That broader context helps leaders allocate testing investment where it will improve reliability the most.

What is a good code coverage percentage?

Most industry guidance recommends 70 to 80% overall coverage as a practical target. Critical modules handling payments, authentication, or data integrity should aim for 90% or higher. The specific target matters less than a consistent upward trend and focused coverage of high-risk areas.

Does high code coverage guarantee high code quality?

No. Coverage measures whether code is executed during tests, not whether the tests validate correct behavior. A test that calls a function without checking its return value contributes to coverage but not to quality. Meaningful assertions and edge case testing matter more than the coverage number alone.

Should code coverage be enforced in CI/CD pipelines?

Yes, with thoughtful thresholds. Enforcing a minimum coverage requirement on pull requests prevents coverage from declining over time. The threshold should be set slightly below the current baseline to avoid blocking all development, then gradually raised as the team builds testing habits.