Coverage

Coverage is the most reported and least understood number in test automation. It measures exactly one thing: which lines of production code were executed while the tests ran. It does not measure whether anything was asserted, whether the assertions were right, or whether the behaviour anybody cares about was exercised.

A test suite with no assertions at all can reach 100% coverage. This is not a hypothetical — it is a well-known way to satisfy a coverage gate.

#What it is genuinely good for

Coverage is a finding tool, not a scoring tool. Its real use is subtractive: point it at your codebase and look at what is red. A module at 0% is either dead code or untested risk, and both of those are worth knowing about. A 4% drop on a pull request tells you someone added a branch and did not test it.

Used that way it is one of the highest-value cheap signals available. Used as a target — "the build fails below 80%" — it reliably produces tests written to move a number. See code coverage for the argument in full, and coverage metrics for why branch coverage is worth roughly three times line coverage as a signal.

#Coverage from the top of the pyramid

End-to-end coverage is the interesting one. Instrument the application, run Playwright or Cypress against it, collect the coverage the browser accumulated, and merge it with the unit run. The result answers a question no other measurement does: which code is only reached by end-to-end tests — which is to say, which code is only protected by your slowest and most fragile tests.

That list is your refactoring backlog.

#The check on the check

Mutation testing deliberately breaks your production code and reports which broken versions your tests still pass. It measures what coverage claims to: whether the tests would actually notice. It is slow, it is worth running on the parts of the codebase where correctness is expensive, and a 90%-covered module with a 40% mutation score is a very common and very alarming discovery.