Best Practices for Code Coverage

This article, originally published on the Google Engineering Blog on August 17, 2020 by Carlos Arguelles, Marko Ivanković, and Adam Bender, presents a set of best‑practice recommendations for using code coverage data to improve software quality and engineering culture.

Code coverage brings significant benefits to developers' workflows by providing an objective, industry‑standard metric that requires little manual effort and is applicable to most products.

Efforts to increase coverage usually foster an excellent engineering culture that ultimately reduces defects.

Pursuing a high coverage percentage alone does not guarantee high‑quality testing; coverage is an indirect, lossy indicator.

Coverage data highlights not only what is covered but, more importantly, what remains uncovered.

There is no universal "ideal" coverage number that fits every product.

Teams should strive to improve coverage comprehensively rather than targeting a single metric.

Obsessing over moving coverage from 90% to 95% yields diminishing returns; incremental improvements are more valuable.

Human judgment about the risk of uncovered code lines is more important than raw line‑coverage percentages.

Even low‑coverage products can make steady, concrete progress toward higher coverage.

While aiming for >90% overall coverage may be unrealistic, targeting ~99% on each commit is reasonable.

Integration and system‑test coverage are also crucial and should be considered alongside unit‑test coverage.

Teams should establish gates that prevent code not meeting coverage standards from reaching production, while avoiding a checkbox mentality.

The article further explains that coverage should be used as a risk‑assessment tool, that increasing coverage encourages teams to treat testing as a first‑class citizen, and that a balanced approach—combining coverage metrics with manual code‑review insights—leads to healthier codebases and more reliable releases.

Google’s internal guidance suggests 60% coverage as acceptable, 75% as commendable, and 90% as exemplary, but teams are encouraged to set thresholds that reflect their product’s risk profile and business needs.