Improve Test Coverage

Improve Test Coverage

Overview

Use this skill to make focused, behavior-driven improvements to test coverage. Prioritize tests that protect important code paths and regressions over superficial coverage percentage gains.

Operating Loop

1. Establish repo state.

   • Run pwd, git status --short --branch, and inspect the project layout.
   • Identify languages, test frameworks, coverage tools, and existing test conventions.
   • Treat uncommitted changes as user work unless you created them. Do not revert unrelated changes.

2. Understand current coverage.

   • Run existing tests and coverage commands when available.
   • Read coverage reports, uncovered-line output, changed files, and critical modules.
   • If no coverage command exists, infer the most appropriate existing test command before adding tooling.
   • Do not chase generated files, vendored code, migrations, snapshots, or framework boilerplate unless the repo already tests them.

3. Choose valuable gaps.

   • Prioritize public behavior, bug-prone branches, error paths, validation, boundary conditions, permissions, data transformations, and integration contracts.
   • Prefer tests that would fail for a plausible regression.
   • Avoid brittle tests that assert implementation details unless the implementation detail is the intended contract.
   • Keep test scope consistent with the repo: unit, integration, component, end-to-end, or snapshot.

4. Add or update tests.

   • Follow existing naming, fixture, factory, mocking, and assertion patterns.
   • Use deterministic data and avoid real network, clock, filesystem, or database dependencies unless existing tests provide safe helpers.
   • Add focused test helpers only when they reduce repeated setup without hiding the behavior under test.
   • Update coverage configuration only when needed to include real source files or exclude non-testable generated artifacts.

5. Verify and iterate.

   • Run the smallest relevant tests first, then the broader suite or coverage command.
   • Fix failures caused by the new tests or exposed bugs.
   • If a test reveals a product bug, fix the production code when the correct behavior is clear; otherwise report the finding and ask before changing behavior.
   • Confirm coverage movement when the repo has a coverage report or threshold.

6. Commit and push when requested.

   • Review git diff and git status --short before staging.
   • Stage only files related to coverage work and any required production fixes.
   • Use a direct commit message such as test: improve coverage for billing validation.
   • Push only when the user asked for it or the task clearly includes pushing.

Coverage Commands

Use references/ecosystems.md when you need ecosystem-specific commands for JavaScript, Python, Ruby, Rust, Go, .NET, Java, PHP, or mobile projects.

Reporting

End with a concise coverage report:

• What changed: tests added or updated and any production fixes.
• Why: coverage gap, regression, branch, edge case, or behavior now protected.
• Verification: exact commands run and their result.
• Coverage movement: percentages, files, thresholds, or report paths when available.
• Git state: commit hash and push result when applicable, or remaining uncommitted files.
• Residual risk: untested gaps, unavailable coverage tooling, skipped slow suites, or pre-existing failures.