Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Code coverage is useful for finding code that automated tests never execute. But hitting a target does not prove that tests check meaningful behavior, exercise important inputs, or catch defects. Treat coverage as a diagnostic signal—not a score to optimize—and build tests around behavior and risk first.
What a coverage percentage tells you—and what it leaves out
Statement coverage records whether a line of code ran during a test. It does not show whether the test checked the line’s result, tried different inputs, or exercised every relevant condition. A test can execute a line and still miss a defect in how that line handles an unusual value.
Google’s Testing Blog put the limit succinctly in its 2008 article, “TotT: Understanding Your Coverage Data”: “Coverage analysis can only tell you how the code that exists has been exercised. It cannot tell you how code that ought to exist would have been executed.” In other words, coverage cannot reveal missing behavior simply because the code for that behavior is absent.
How 100% coverage can still miss a bug
Google illustrates this with a recoverable-error case: tests can reach 100% coverage without checking that the program handles an error it should recover from. The tests execute the existing lines, but they do not establish that the system behaves correctly in that scenario. This is why a high percentage can coexist with a meaningful gap.
Why chasing a target can make a test suite less useful
A target becomes counterproductive when developers optimize the measured percentage rather than the confidence tests provide. If the task is framed as “cover the remaining lines,” teams may add tests that execute code but assert little, or favor easy-to-reach lines over higher-risk behavior. Those tests can raise the metric without addressing the defects that matter.
This is a conditional warning, not an argument that coverage is useless. Coverage is an indirect signal: it can point to code the automated suite has not executed and prompt a focused review. It is not a direct measure of correctness or test quality. Google’s 2020 guidance on code coverage best practices likewise cautions against treating any percentage as universally ideal.
How to set a coverage expectation without mistaking it for a quality score
There is no single threshold that fits every project. Decide what level of coverage is useful in context, and make clear whether the expectation applies to the whole project or to changed code. Google’s 2020 article describes its own internal guidelines as 60% “acceptable,” 75% “commendable,” and 90% “exemplary,” while advising teams to choose values suited to their business needs. Those figures are Google’s guidance, not an industry standard.
Consider these factors when setting or revisiting a target:
- Business criticality: A failure in core decision logic may warrant more scrutiny than an unimportant logging line.
- Change frequency: Frequently changed code can merit closer, ongoing test attention.
- Expected lifespan: Long-lived code may justify a different investment than short-lived code.
- Complexity and domain variables: More branching or more consequential input variation can call for tests that examine cases a line-based percentage does not capture.
- Scope of the target: A project-wide percentage can conceal weak coverage in new work; a changed-code expectation can focus attention on what is being added or modified.
- How the metric is reviewed: The percentage is more informative when examined alongside the actual uncovered lines and the tests’ assertions.
A practical workflow for using coverage well
- Start with behavior and risk. Identify what the code should do, what could go wrong, and which cases matter. Design comprehensive test cases rather than choosing only the cases needed to raise the percentage.
- Inspect the coverage report. Use it to find code the automated tests did not execute and to notice unexpected patterns. A low-coverage area is a prompt for review, not proof that every uncovered line needs a test.
- Assess gaps in context. Consider the consequence of a failure and the role of the uncovered code. A debug-log line and a critical decision branch do not carry equal risk.
- Test meaningful gaps and boundaries. Add tests for important behavior, including relevant edge cases that may occur within lines already counted as covered. Check that tests assert the intended result, not merely that execution completed.
- Consider mutation testing as a complement. Mutation testing changes code in selected ways to check whether tests detect those changes. Review surviving mutants to understand what the suite may not catch; a surviving mutant is a prompt for analysis, not automatically a real defect. Google’s guidance supports mutation testing as a complement, but does not establish a universal mutation score.
- Repeat when the risk reduction warrants the cost. Improve tests where they add useful confidence, and consider refactoring code that is unusually difficult to test.
How to tell whether a test adds confidence
For each test, ask what behavior it protects and what failure it would detect. A test that only runs a line may confirm execution while leaving the result unchecked. Stronger tests make the expected behavior explicit and choose inputs that matter to the feature’s risks, including relevant boundaries and error cases.
Mutation testing can help probe that distinction: if a selected behavior change does not cause a test to fail, inspect whether the behavior is asserted or whether the changed code matters. Use the result to guide review, not as a replacement for understanding the system’s intended behavior.
Rank #4
What the available evidence does—and does not—establish
Google Research’s 2019 paper abstract describes infrastructure analyzing one billion lines of code daily across seven programming languages. It also reports 512 survey responses from 3,000 developers. These figures describe the paper’s infrastructure and survey; they do not establish that a particular coverage target causes weaker tests across teams.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The practical case for caution is narrower and more useful: coverage measures execution of existing code, while test quality also depends on behavior asserted, inputs explored, and whether the expected behavior exists at all. The cited guidance supports using coverage to find gaps and inform review, not treating it as a standalone verdict.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
