coverage-analysis

Read branch coverage rather than line coverage, then open the HTML report and review red regions ranked by risk: uncovered error paths in money, auth, and data-writing code first, then complex conditionals, then whole uncovered files. The aggregate percentage hides exactly the gaps that matter.

A single percentage cannot answer that. A repo at 85% with untested billing error paths is worse tested than one at 70% with only cosmetic gaps. Set tiered targets instead: 90%+ branch coverage for core domain logic, 60-80% for adapters, best-effort for UI and scripts.

Use branch coverage. One line like `if user.is_admin or order.total > limit` contains four meaningful paths, and line coverage reports 100% when only one path ran. Enable it with pytest --cov --cov-branch, go test -covermode=count, or equivalent settings in Istanbul and JaCoCo.

Your tests execute code without asserting on its behavior, so mutations survive. Run a mutation spot-check: flip a comparison or remove a guard in high-risk code and rerun the suite. Tools like mutmut, pitest, or Stryker automate this on critical packages.

Not before checking whether the code is reachable at all. Use git log and grep for callers; uncovered code is often dead code, and deleting it beats testing it. Only after confirming the code is live should you decide between testing and accepting the gap.