What they're testing
Whether you separate a metric from a goal. It's the textbook case of Goodhart's law.
The short answer~30 seconds
It says 90% of lines executed while the tests ran — not that any assertion checked the result. A suite that calls every function and asserts nothing still reports 100%. I use coverage in the opposite direction: I read the UNCOVERED part to find forgotten branches, rather than setting a number as a target.
The long answer
There are several kinds and they claim different things. Line coverage is the easiest to reach and the weakest. Branch coverage is stronger: it demands both the if and the implicit else, and the forgotten else is precisely where bugs live. Condition coverage goes further, requiring each sub-condition of a compound expression to take both values. Knowing the difference shows you understand the metric rather than reading the number.
A mandated CI threshold has a predictable side effect: people write tests for whatever is easiest to cover — getters, DTOs, generated code — because that's the cheapest way to move the number. Meanwhile the hard-to-cover parts (error handling, unusual paths) are exactly what most needs testing, and they're what gets left. So a mandated threshold can make a suite worse while the number improves.
What I care about more than coverage is mutation testing: a tool makes small edits to your code (flip a comparison, change a constant) and checks whether any test goes red. If the code is broken and the suite stays green, that test verifies nothing. It's much slower so it usually runs on a schedule rather than blocking PRs, but it answers the question coverage cannot.
What they'll ask next
?So what coverage number is reasonable?
I don't set one number for a project but a number per area: business logic and money maths should be close to fully covered, wiring and configuration can be low. A single repo-wide figure is always simultaneously too strict in one place and too lax in another.
These lose points
- Treating 100% as the goal. It rewards testing things not worth testing and still says nothing about assertion quality.