test-coverage-strategy

Guide test-suite planning using structural coverage criteria like line, branch, and MC/DC.

1|Updated May 6, 2026
One-click install
npx skills add https://github.com/jacob-balslev/skill-graph --skill test-coverage-strategy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-coverage-strategy
Source: https://github.com/jacob-balslev/skill-graph/tree/main/marketplace/skills/test-coverage-strategy
Command: npx skills add https://github.com/jacob-balslev/skill-graph --skill test-coverage-strategy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps teams use code coverage as a diagnostic signal for test-suite gaps, while avoiding the common mistake of treating coverage percentages as a quality target (a Goodhart’s Law failure mode).

Core Features & Use Cases

  • Coverage-criterion hierarchy: Explains how coverage levels differ in granularity (function, statement/line, branch, decision, condition, MC/DC, path) and what each level can and cannot reveal.
  • Floor vs ceiling thinking: Clarifies that uncovered code is reliably “untested,” while covered code is not automatically “verified,” preventing misleading conclusions.
  • When granularity matters: Uses safety-critical standards (DO-178C and ISO 26262) as evidence that the right criterion (e.g., MC/DC) depends on the code’s failure modes.
  • Practical application boundaries: Provides explicit guidance on what to avoid (e.g., don’t use this skill for choosing test levels or configuring tooling; use the dedicated related skills instead).

Quick Start

Use the test-coverage-strategy skill to explain whether a coverage metric like line coverage or branch coverage is a helpful gap signal for your codebase, and what more appropriate criterion you should consider based on the code’s failure modes.

Frequently Asked Questions about test-coverage-strategy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is the difference between covered code and tested code in branch coverage metrics?

Code coverage metrics like line coverage identify untested gaps by showing uncovered code, but covered code is not automatically verified, requiring a floor-not-ceiling interpretation to avoid mistaking execution for actual behavior verification.

When do I need MC/DC coverage instead of standard branch coverage?

MC/DC coverage is required for safety-critical software in domains governed by DO-178C or ISO 26262 standards, where standard branch coverage is insufficient because failure modes demand condition-level granularity to verify independent boolean variable effects.

How do I use code coverage as a diagnostic signal without gaming the metric?

To use code coverage as a diagnostic signal without gaming the metric, find untested gaps rather than chasing a target percentage, avoiding Goodhart's Law failures and coverage-padding anti-patterns by distinguishing structurally exercised code from verified behavior.

What are the structural test coverage levels from function coverage to path coverage?

Structural test coverage levels include function, statement/line, branch, decision, condition, MC/DC, and path coverage, increasing in granularity where higher levels like MC/DC reveal independent boolean condition effects that lower levels such as line coverage cannot expose.

Why does treating code coverage as a quality target lead to metric gaming?

Treating code coverage as a quality target triggers Goodhart's Law, where the metric loses diagnostic value as teams pad coverage with low-value tests, making it a ceiling rather than a floor for finding actual untested gaps in the test suite.