The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Yes: a project can report 90% code coverage and still ship a bug. Coverage records which code ran under a chosen metric; it does not prove that tests checked the right results, exercised risky inputs, or would detect incorrect behavior. AI-generated tests can have the same limitation.
What 90% code coverage actually tells you
Coverage is a measure of execution under a particular metric. Statement coverage, for example, reports whether a source line ran during a test. It does not show that every possible input or execution path was exercised. Google’s explanation of coverage data illustrates the gap: a division line may run with a nonzero divisor even if no test checks division by zero.
As an Amazon Associate I earn from qualifying purchases.
As the Google Testing Blog put it in 2020, “Code coverage does not guarantee that the covered lines or branches have been tested correctly, it just guarantees that they have been executed by a test.” A covered line can contain a defect or mishandle an edge case while still counting toward the percentage. The Fuchsia coverage documentation makes the same distinction: “Test coverage does not guarantee bug-free code.”
Recommended Free Tools
How can a bug ship when coverage is 90%?
The percentage can be high while the tests leave important questions unanswered. A test might call a function but never verify its returned value; check a typical input but skip a boundary condition; or assert that an operation completed without checking the failure condition that matters to users. In each case, code can execute and register as covered without the test proving the intended behavior.
This applies to AI-generated tests too. A generated test may call a code path and increase coverage while making weak or incomplete assertions. That is an application of the general limitation of coverage, not evidence of a particular AI incident or an AI-specific failure rate.
Is there an ideal code coverage percentage?
No percentage fits every product or team. Google’s 2020 code coverage guidance gives 60% as “acceptable,” 75% as “commendable,” and 90% as “exemplary” general guidelines, while explicitly noting there is no universal ideal. Those labels are Google’s guidance, not an industry-wide standard or a guarantee of quality.
Choose a threshold as a local risk-management decision. Google says the testing level should reflect factors such as a feature’s business impact or criticality, how often its code changes, its expected remaining lifetime, its complexity, and relevant domain variables. A percentage can help expose untested areas, but it should not become a substitute for deciding which failures matter most.
How to make a coverage report useful
- Find the uncovered code. Use the report to identify lines or branches tests did not execute. Treat those gaps as places to investigate, not an automatic verdict on quality.
- Prioritize by risk. Review uncovered and covered code in light of its criticality, complexity, change rate, expected lifetime, and domain-specific risks.
- Check what each test asserts. For important scenarios, confirm that tests verify meaningful outputs, state changes, errors, and boundary behavior—not merely that a call ran.
- Consider whether tests would notice a defect. Mutation testing deliberately changes code and checks whether tests detect the change. Google recommends it as a way to find false coverage: code that executes under tests whose checks may be too weak.
- Use complementary techniques where they fit. Fuzzing explores input variations; static and dynamic analysis can address other classes of defects. None of these measures replaces the others or proves software defect-free.
A Google Research paper on its mutation-testing system reported that, in more than 90% of cases in its code base, either all mutants in a line were killed or none were. That is a result from that particular system and code base—not a general guarantee about mutation testing or a measure of how often it finds real-world defects.
What each testing signal can—and cannot—show
| Approach | What it observes | What it can reveal | Practical scope |
|---|---|---|---|
| Code coverage | Whether code was executed under the selected coverage metric | Code that tests did not reach | Useful for finding gaps; it does not establish that covered behavior was checked correctly |
| Mutation testing | Whether tests detect selected deliberate code changes | Tests that fail to catch those changes | Tests the sensitivity of a suite to chosen mutations; results depend on the mutations used |
| Fuzzing | Program behavior across generated or varied inputs | Failures triggered by inputs explored during fuzzing | Explores input variation; it does not establish correctness for every possible input |
| Static and dynamic analysis | Other code or runtime properties, depending on the analysis | Some defect classes those analyses are designed to detect | Complementary techniques; neither subsumes coverage or behavioral tests |
Fuchsia’s documentation recommends combining coverage with fuzz testing and static and dynamic analysis. The appropriate combination depends on the risks and system; no single percentage or technique answers every testing question.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Keep coverage as a signal, not a target
A 90% result is meaningful only when read as a statement about execution under a specified metric. To judge whether a test suite protects important behavior, look beyond the number: identify gaps, inspect assertions, and consider whether the tests would detect plausible defects in high-risk paths.
Quick Recap
Best Value
Rank #4
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.
