agentleFS
drvossdrvoss/everything-copilot-cli/skills/testing/test-coverage/SKILL.md

test-coverage

Skill48 starsChanged 17 days agoMITView on GitHub

Use when test coverage falls below target or a new module has no tests — identifies untested code paths and writes targeted unit or integration tests to close the coverage gap.

20 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use instinct-export, instinct-import and 7 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • TheKREATORSSkill

    instinct-export

    Export instincts from project/global scope to a file

    Also in 3 projects that use this

  • TheKREATORSSkill

    instinct-import

    Import instincts from file or URL into project/global scope

    Also in 3 projects that use this

  • diego-tobalinaSkill

    build-fix

    Fix build and compilation errors systematically. Run when build fails.

    Also in 3 projects that use this

  • qtzx06Skill

    eval

    Evaluate trained YOLO model accuracy with mAP metrics and per-class error analysis. Identifies failure cases for targeted improvement. Use after training.

    Also in 4 projects that use this

  • Microsoft AzureSkill

    iterative-retrieval

    Max-3-cycle protocol for agent sub-tasks with WHY context and coordinator validation. Use when spawning sub-agents to complete scoped work.

    Also in 3 projects that use this

  • iovisorSkill

    evolve

    Evolve uBPF through a gated spec-first workflow that propagates approved changes through requirements, design, validation, implementation, and RFC alignment artifacts.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 8 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 19 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Test framework configured with coverage reporting

    line 22
  2. Distinctive:

    Default cases in switch statements

    line 114
  3. Distinctive:

    No tests for error paths (catch blocks, failure cases)

    line 173
  4. Distinctive:

    Only happy path tested, no edge cases

    line 176
  5. Distinctive:

    Test behavior, not implementation — tests should survive refactoring

    line 190
  6. Very specific:

    Use explore agent to understand complex functions before writing tests

    line 191
  7. Distinctive:

    Write the test name first as a sentence describing expected behavior

    line 192
  8. Distinctive:

    If code is hard to test, it may need refactoring (dependency injection, smaller functions)

    line 193
  9. Distinctive:

    Add coverage thresholds to CI so coverage can't silently regress

    line 194

“Common” is measured: kept by at least 6 in 10 of the 19 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Test Coverage Improvement

When to Use

  • Coverage reports show critical modules below target thresholds
  • New code was merged without sufficient test coverage
  • Preparing for a release and need confidence in code correctness
  • Refactoring requires a safety net of comprehensive tests
  • Team has set a coverage target that needs to be met

Prerequisites

  • Test framework configured with coverage reporting
  • Baseline coverage report available or generatable
  • Understanding of which code is critical vs. low-risk

Workflow

1. Generate a Coverage Report

# Node.js / Jest
npm test -- --coverage 2>&1 | Select-Object -Last 30

# With specific thresholds
npm test -- --coverage --coverageReporters="text" 2>&1

# Python / pytest
pytest --cov=src --cov-report=term-missing 2>&1

# Go
go test -coverprofile=coverage.out ./... && go tool cover -func=coverage.out

2. Identify Uncovered Code

# Find files with lowest coverage (Jest text output)
npm test -- --coverage --coverageReporters="text" 2>&1 | Select-String "\d+\.\d+\s*\|" | Sort-Object { [double]($_ -split '\|')[1].Trim().TrimEnd('%') }

# Generate detailed HTML report for visual inspection
npm test -- --coverage --coverageReporters="html"
# Report is in coverage/lcov-report/index.html

3. Prioritize What to Test

Focus testing effort where it matters most:

PriorityWhat to CoverWhy
🔴 HighBusiness logic, calculationsBugs here cost money
🔴 HighAuthentication, authorizationSecurity-critical
🟡 MediumData transformations, parsersCommon source of bugs
🟡 MediumError handling pathsOften untested, often broken
🟢 LowSimple getters/settersLow risk
🟢 LowUI layout componentsBetter tested with E2E

4. Write Targeted Tests

For each uncovered function or branch:

# View the uncovered code
# Coverage report shows line numbers — use view tool to see the code

# Find existing test file (or create one)
glob pattern="**/*moduleName*.test.*"
// Test the happy path
describe('calculateDiscount', () => {
  it('applies 10% discount for orders over $100', () => {
    expect(calculateDiscount(150)).toBe(135);
  });

  // Test edge cases and branches
  it('returns original price for orders under $100', () => {
    expect(calculateDiscount(50)).toBe(50);
  });

  it('handles zero amount', () => {
    expect(calculateDiscount(0)).toBe(0);
  });

  // Test error paths
  it('throws for negative amounts', () => {
    expect(() => calculateDiscount(-10)).toThrow('Amount must be non-negative');
  });
});

5. Target Uncovered Branches

# Find conditional logic that may lack branch coverage
grep -n "if\|switch\|? .*:\|&&\|||" src/target-module.ts

Common branch gaps:

  • else clauses
  • catch blocks
  • Default cases in switch statements
  • Short-circuit evaluation (&&, ||)
  • Ternary operators
  • Early returns

6. Measure Improvement

# Run coverage again and compare
npm test -- --coverage --collectCoverageFrom="src/target-module.ts" 2>&1

# Verify overall coverage meets target
npm test -- --coverage 2>&1 | Select-String "All files|Statements|Branches"

Examples

Cover Error Handling

// Source: src/api/client.ts has uncovered catch block
describe('apiClient.fetch', () => {
  it('retries on network error', async () => {
    const mockFetch = jest.fn()
      .mockRejectedValueOnce(new Error('Network error'))
      .mockResolvedValueOnce({ ok: true, json: () => ({ data: 'ok' }) });

    const result = await apiClient.fetch('/endpoint', { fetch: mockFetch });
    expect(mockFetch).toHaveBeenCalledTimes(2);
    expect(result.data).toBe('ok');
  });

  it('throws after max retries', async () => {
    const mockFetch = jest.fn().mockRejectedValue(new Error('Network error'));
    await expect(apiClient.fetch('/endpoint', { fetch: mockFetch }))
      .rejects.toThrow('Network error');
  });
});

Using task Agent for Coverage Runs

task agent_type: "task"
prompt: "Run 'npm test -- --coverage' and report the coverage summary. List any files below 80% line coverage."

Common Rationalizations

RationalizationReality
"80% coverage is good enough"80% is the minimum. What matters more is which 20% isn't covered.
"100% coverage is impractical"Core business logic and security-critical code should still target 90%+ branch coverage.
"High coverage means high quality"Coverage measures lines executed, not assertion quality.
"This file is hard to test"Hard-to-test code is a signal of poor design. Improve the interface.

Red Flags

  • High coverage numbers but tests with no assertions (expect(true).toBe(true))
  • No tests for error paths (catch blocks, failure cases)
  • Coverage drops when new features are added
  • Far fewer test files than source files
  • Only happy path tested, no edge cases

Verification

  • npm run coverage result meets or exceeds the baseline
  • Newly added files have ≥80% coverage
  • Tests exist for all error handling paths
  • Uncovered lines in the coverage report have been reviewed
  • Files/paths excluded from coverage are documented

Tips

  • Don't chase 100% — aim for 80%+ overall, 90%+ on critical paths
  • Cover branches, not just lines — branch coverage catches more bugs
  • Test behavior, not implementation — tests should survive refactoring
  • Use explore agent to understand complex functions before writing tests
  • Write the test name first as a sentence describing expected behavior
  • If code is hard to test, it may need refactoring (dependency injection, smaller functions)
  • Add coverage thresholds to CI so coverage can't silently regress

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.