80% coverage. Does that let you sleep at night?

Coverage is one of the most misleading metrics in software quality. From coverage as a target to coverage as a compass.

80% coverage. It's on the dashboard, it's green, and it feels good. The only question is: what exactly does that number give you certainty about?

Coverage is one of the most used and most misunderstood metrics in software quality. Not because it's a bad metric, but because people read something into it that isn't there.

What coverage actually tells you

Coverage tells you which part of your code (or your requirements, depending on how you measure it) is touched by at least one test. That's useful information. If 40% of your code is never exercised by a test, you know where your blind spots are.

What coverage doesn't tell you

And that's the trap. High coverage doesn't automatically mean you have good tests. A test that merely calls a function without checking anything still increases your coverage. So does a test that only walks the happy path and skips important edge cases.

You can have 90% coverage on a codebase that fails the moment a user does something unexpected. And you can have 60% coverage on a codebase that's solid, because that 60% covers exactly the critical paths and is thoroughly tested.

The danger of the number as a target

The moment coverage becomes a target, "we need to hit 80%", it starts shaping its own reality. Teams write tests to hit the number, not to cover risk. They test getters and setters, because that's quick. They leave the complicated, risky logic alone, because a good test there takes time.

The result: a higher number, but no more certainty. That's not harmless, it's harmful. Because that number gets used to make decisions.

The shift: from target to compass

Coverage is at its best as a diagnostic tool, not a goal. Use it to ask questions, not to answer them.

• Which parts of the code do we never touch? And does that matter?
• Is our critical business logic better covered than our edge functionality?
• Is our coverage suddenly dropping? What happened?
• Where do we have a lot of code and few tests? That's where our risk sits.

The question that actually matters

Not: "do we hit 80%?" But: "do we dare ship to production on Tuesday afternoon?"

If the answer is yes, and your coverage is 65%, nothing's wrong. If the answer is no, and your coverage is 85%, you're measuring the wrong thing.

Quality isn't a percentage. It's trust, and you earn that with tests that actually mean something.