test-coverage-strategy
Test-Coverage Strategy
Concept of the skill
What it is: Test-coverage strategy is the discipline of using structural coverage reports to identify unexercised code and to choose an appropriate coverage criterion — without treating the percentage as proof of test-suite quality.
Mental model: Coverage is a reach map. The map gets more precise as the criterion gets stronger — functions, lines, branches, decisions, conditions, MC/DC independence, and paths each reveal a different kind of gap. The map still does not know whether a test asserted the right behavior. So coverage is a reliable floor (uncovered code is definitely untested) and an unreliable ceiling (covered code is not necessarily tested).
Why it exists: The coverage number is easy to produce and easy to gate on, and the moment it becomes the goal, tests degrade into reach-without-assertion padding. As of the LLM era that padding is now produced at scale by AI test generators, not just by humans gaming a gate. The skill keeps the strong floor signal and blocks the weak ceiling claim.
What it is NOT: It is not test-level selection, mutation testing, test-double construction, TDD, LLM eval design, production observability, or coverage-tool configuration.
Adjacent concepts: testing strategy, mutation testing, test doubles, TDD, requirements traceability, property/fuzz testing, contract/integration testing, and production observability.
One-line analogy: A green coverage map is like a green cell-phone coverage map — it shows where there is theoretical signal, not whether the call gets through. A 100% coverage map with a 30% call-completion rate is the same shape of problem as a 100%-line-coverage suite that misses bugs.
Common misconception: Higher coverage is not automatically better. A coverage report measures execution; only assertions, oracles, requirements, mutations, properties, contracts, or integration evidence tell you whether the reached behavior was verified.