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

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

You have commissioned 80% coverage. You have not commissioned quality, and you have told every engineer exactly what to optimise for.

I have never seen a coverage target raise the quality of the software. I have seen it raise the coverage number. They are different things, and the gap between them is where the bugs live.

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

It is like proving you cleaned the kitchen by showing a photo of the tap running. Water was present. Cleanliness was not confirmed.

If not coverage, 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, and never pay people to colour them in.

A team chasing a coverage badge will reach it. They will stop testing whatever does not count toward the number, which is reliably the code that breaks.

See how your own suite measures up: a QA Review scores your test coverage, tooling and process in one to two weeks.