Coverage targets are Goodhart's Law in a hi-vis jacket

"We've mandated 80% coverage across every repo."

Congratulations. You've just commissioned 80% coverage. You have not commissioned quality, and you've quietly told every engineer on the floor exactly what to optimise for.

In 20 years of walking into release processes held together with hope and a muted CI pipeline, I've never once seen a coverage target raise the quality of the software. I've seen it raise the coverage number. Those are not the same thing, and the gap between them is where the bugs live.

This is Goodhart's Law wearing a hi-vis jacket: when a measure becomes a target, it stops being a good measure. The moment 80% is the goal, smart engineers do the rational thing — they hit 80%. They write tests that execute every line and assert almost nothing. The line gets touched, the coverage tool goes green, and nobody has actually checked whether the code does the right thing.

It's the testing equivalent of proving you cleaned the kitchen by showing a photo of the tap running. Water was present. Cleanliness was not confirmed.

So what do you measure instead? Honestly — measure less, and look harder:

• Escaped defects, not executed lines. What reached production, and what would have caught it?
• Mutation testing on the code that matters. If you change the logic and every test still passes, your suite is decoration.
• Mean time to detect, not percentage covered. A fast, honest signal beats a high, hollow one.
• Coverage as a conversation, not a gate. "This module is at 30% — should it be?" is a far better question than "the dashboard says red."

Use coverage to find blind spots. Just never pay people to colour them in.

A team chasing a coverage badge will always reach it. They'll simply stop testing the things that don't count toward the number — which, reliably, are the things that break.

What's the metric your team games without ever quite admitting it?