# Improve Test Coverage

> Operational support for application test coverage improvement. Use when Codex needs to inspect existing test suites and coverage reports, identify meaningful coverage gaps, add or update tests, improve edge-case and regression coverage, run coverage/test commands, iterate on failures, summarize remaining risk, and optionally commit or push verified test-coverage changes.

- Skill: `breroz/improve-test-coverage` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add breroz/improve-test-coverage`
- Raw SKILL.md: https://api.skillmd.com/api/skills/breroz/improve-test-coverage/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: BreRoz (https://skillmd.com/u/breroz)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/breroz/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](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.