What test coverage percentage should you actually aim for?

Short answer: aim for 80 percent line coverage, and stop treating the last twenty points as a moral failing.

Here is the longer version, because the number gets argued about more than almost anything in engineering.

Why 80, not 100

The cost of coverage is not linear. Getting from 20 to 60 percent is mostly covering the core logic that any sane test plan would hit. Getting from 60 to 80 is covering the realistic error paths. Getting from 80 to 100 is covering defensive branches that almost never run, generated code, framework boilerplate, and platform-specific guards.

That last stretch costs three to five times more effort per point and buys close to nothing in real defect prevention. Teams that mandate 100 percent end up writing tests that exist only to touch a line, which is how you get a green bar that catches no bugs. The consensus across most mature engineering orgs lands in the 70 to 85 percent band for exactly this reason.

The number is a proxy, and proxies get gamed

Coverage measures whether a line ran during the test, not whether the test would catch a break. Those are different things. A suite can hit 90 percent and still miss every meaningful regression if the tests assert nothing.

So the number is useful as a floor and a trend, not as a target to optimize blindly. A healthy rule: coverage should not drop on a pull request, and new code should ship with tests. That keeps the trend right without inviting the padding games that a hard 100 percent mandate creates.

Where higher than 80 is worth it

Some code earns the extra points. Payment handling, auth, anything that moves money or data, and safety-critical paths are worth pushing to 90 percent or higher, because the cost of a miss there is an incident, not a typo. The point is to spend the expensive coverage where the risk is, not spread it evenly to satisfy a dashboard.

A practical target to adopt

New code: ships with tests, no exceptions.
Whole repo: 80 percent line coverage as the standing target.
High-risk modules (money, auth, data writes): 90 percent or higher.
Coverage on a pull request: never goes down.

That is a target you can actually hold, and it focuses the work on behavior that matters instead of chasing a number that lies.

See where you stand

Curious what your repo reports today? Run a free coverage check: paste a public GitHub repo and we clone it, run its suite, and give you the real number in a couple of minutes. If you are below 80 and want to get there without stalling a sprint, Coverage Uplift does it as a flat-price service, verified in a sandbox against your own tests, refund in full if we miss.