mcpField
E
engram-testing-coverage

engram-testing-coverage

github.com/gentleman-programmingTesting & quality7.7k98 installsUpdated today
Repository

About engram-testing-coverage

engram-testing-coverage is a testing skill for contributors changing behavior, fixing bugs, or refactoring complex logic. It sets out a TDD loop and evidence-based local and CI verification guidance.

Key features

  1. 01Failing-test-first TDD loop
  2. 02Happy-path and edge-case coverage
  3. 03Deterministic test preference
  4. 04Focused local regression checks
  5. 05CI evidence and reporting guidance

Use cases

  1. 01Adding behavior with tests
  2. 02Reproducing and fixing a bug
  3. 03Refactoring branching logic
  4. 04Recording verification for a pull request

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/gentleman-programming/engram --skill engram-testing-coverage

After installing, type/engram-testing-coveragein Claude Code to confirm it loaded.

Details

From the project README

When to Use

Use this skill when:

  • Adding new behavior
  • Fixing a bug
  • Refactoring logic with branch complexity

TDD Loop

  1. Write a failing test for the target behavior.
  2. Implement the smallest code to pass.
  3. Refactor while keeping tests green.
  4. Add edge/error-path tests before closing.

Coverage Rules

  • Cover happy path + error paths + edge cases.
  • Prefer deterministic tests over flaky integration paths.
  • Add seams only when branches are impossible to trigger naturally.
  • Keep runtime behavior unchanged when adding seams.

Verification Ownership

Verification is evidence about the candidate; CI is the automated execution venue, not a substitute for local focused evidence.

  • For behavior changes, run a focused regression test and tests for the affected package(s) locally before proposing the change. Report the commands and outcomes.
  • Use targeted coverage when useful to find missed behavior or branches. Do not require a numeric coverage target or total module coverage for every PR.
  • After the candidate is pushed to a PR, GitHub CI owns the full unit suite (go test ./...), E2E suite (go test -tags e2e ./internal/server/...), lint, and applicable platform checks. Do not report CI evidence until those checks actually run.
  • When there is no PR or the candidate is unpushed, or when risk justifies more verification, run the additional applicable checks locally. Report checks that could not run as missing evidence rather than claiming CI covered them. Avoid duplicating the broad suite locally by default when PR CI will run it.

Comments

Markdown supported