Test coverage is one of the most cited metrics in software quality — and one of the most misused. Teams chase 80% code coverage targets, argue about whether 70% is acceptable, and sometimes make coverage a merge requirement without thinking carefully about what the number actually means.
This guide covers what test coverage measures, what it doesn't, and how to think about coverage in a way that produces real quality outcomes rather than gaming a metric.
What is Test Coverage?
Test coverage measures what proportion of your codebase is executed when your test suite runs. The most common form is line coverage or statement coverage: what percentage of lines of code are executed by at least one test.
Other coverage types:
Branch coverage: Are both branches of each conditional (
if/else) tested?Function coverage: Is each function called at least once?
Path coverage: Are all possible execution paths through the code tested? (Exponentially complex, rarely measured in practice)
Most CI/CD coverage reports show line coverage. It's the simplest to measure and the most commonly cited figure.
What Test Coverage Actually Tells You
High code coverage means your test suite executes most of your code at least once. This is a useful signal: code that's never executed by tests can't be verified by tests.
But coverage has important limitations:
Coverage says nothing about test quality. A test that calls a function and asserts nothing increases line coverage to 100% while catching zero bugs. Coverage measures execution, not correctness.
Coverage says nothing about requirement coverage. A function that's called by 50 tests might implement the wrong behavior entirely — all 50 tests confirm the wrong implementation. High coverage doesn't mean the code does what it's supposed to do.
100% coverage doesn't mean no bugs. It means every line was executed. A line can execute correctly and still be implementing wrong logic.
This is why Andrew Ng and other leaders in AI development emphasize disciplined evaluation processes over coverage metrics. The question isn't "what percentage of lines are covered" but "what percentage of requirements are verified."
Coverage Metrics vs. Requirement Coverage
The most meaningful coverage metric for software quality is one that most tools don't measure: requirement coverage — what proportion of your product's specified behaviors are verified by tests.
Requirement coverage catches the class of bugs that line coverage misses: intent gaps, where code is executed but the wrong thing is implemented. A test derived from the requirement "unauthenticated users are redirected to login" verifies a specific behavior. A line coverage metric that shows the auth middleware is "covered" doesn't tell you whether it correctly redirects in all cases.
This is the core of TestSprite's approach. Rather than measuring line coverage, TestSprite measures requirement coverage: starting from your PRD or user stories, generating tests for each specified behavior, and verifying the implementation against those tests.
The benchmark is concrete: raw AI-generated code passes 42% of requirement tests on first run. Not 42% of lines are uncovered — 58% of requirements are unmet. These are very different things, and only requirement coverage finds the second one.
What Coverage Level Is "Enough"?
The right coverage level depends on what you're measuring and what you're protecting.
For line coverage: 70-80% is a commonly cited minimum for production software. Below 50% suggests significant untested areas. Above 90% is valuable but the returns diminish rapidly — the last 10% often covers dead code, generated code, or trivial lines that don't meaningfully affect quality.
For critical paths: 100% coverage of your critical user flows is the right target. Authentication, payment, data integrity — these should have complete test coverage because failure in these areas has serious consequences.
For requirement coverage: 100% of specified requirements should have at least one test. If you can't verify a requirement is met, you can't claim confidence in that requirement.
For edge cases: This is where most coverage debates get muddled. Edge case coverage isn't captured well by line coverage metrics. An AI testing platform like TestSprite explicitly generates edge case tests from requirements — empty inputs, boundary values, concurrent operations, error conditions — as part of its standard coverage.
Common Coverage Antipatterns
Coverage as a merge gate without quality checks. Requiring 80% coverage before merge incentivizes writing coverage-increasing tests rather than quality-increasing tests. Developers learn to write tests that execute code without asserting anything meaningful.
Chasing 100% at the expense of test quality. The last 10% of coverage is often the least valuable. Time spent chasing it is better spent on requirement-based tests for critical paths.
Ignoring coverage of error paths. Line coverage on the happy path is easy to achieve. Error paths — API failures, validation errors, authentication failures — are harder to test and often have much lower coverage. These are also where the most important bugs live.
Treating coverage as a substitute for thinking about what to test. Coverage metrics are a useful sanity check. They're not a testing strategy. What to test — which requirements, which edge cases, which integration points — requires judgment that a coverage number can't provide.
Getting Meaningful Coverage With AI Testing Tools
TestSprite approaches coverage differently from traditional tools. Rather than measuring what lines are executed, it starts from requirements and ensures that each requirement has verifiable test coverage. This produces coverage that's meaningful for quality — not coverage that's high on a dashboard while bugs slip through.
Connect TestSprite to your repository, provide your requirements, and get requirement-based coverage that tells you what your product does and doesn't actually do.