agentleFS
SkillMedevSkillMedev/qa-test-automation/skills/mutation-test-runner/SKILL.md

mutation-test-runner

Skill0 starsChanged 39 days agoMITView on GitHub

Runs mutation testing on already-covered code and turns each surviving mutant into a specific missing assertion, exposing tests that execute code but verify nothing. Use when line coverage is high yet a bug slipped through, when reviewing a critical module (pricing, permissions, auth, state machines) before release, or when you are asked to run Stryker, PIT, mutmut, or cosmic-ray. Do NOT use when the goal is to find which code paths are untested at all - use coverage-gap-finder instead.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run scoped, not global. In CI, mutate only changed files (Stryker incremental / diff mode).

    line 15
  2. Distinctive:

    Read each surviving mutant as a named missing assertion, not a vague gap:

    line 16
  3. Distinctive:

    Every reported survivor maps to one concrete, named assertion a developer can write - no "add more tests."

    line 26
  4. Distinctive:

    Do NOT block every PR on a full-repo mutation run - it reruns the suite per mutant and will stall the pipeline.

    line 33
  5. Distinctive:

    Do NOT chase a 100% mutation score.

    line 34
  6. Distinctive:

    Do NOT run mutation testing on generated code, DTOs, or glue - spend the compute where a silent failure hurts.

    line 35
  7. Distinctive:

    Do NOT use a single global threshold.

    line 36
  8. Distinctive:

    Do NOT treat mutation testing as a substitute for deciding what to test.

    line 37

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Mutation Test Runner

Prove whether covered code is actually verified: deliberately break a line, and check that a test notices. A surviving mutant is proof that the line is executed but unasserted.

Workflow

  1. Pick the target. Scope to high-risk logic where a silent bug is expensive - pricing, permissions, auth, state machines, financial math. Skip generated code, trivial DTOs, and glue; they have nothing worth mutating.
  2. Pick the runner: Stryker (JS/TS/C#), PIT (JVM), mutmut or cosmic-ray (Python). Configure it to run against the target's existing test suite.
  3. Run scoped, not global. In CI, mutate only changed files (Stryker incremental / diff mode); reserve a full sweep for a nightly job. Enable coverage analysis so only tests touching a mutated line rerun, and parallelize across cores.
  4. Read each surviving mutant as a named missing assertion, not a vague gap:
    • < mutated to <= survives -> the boundary case is unasserted; add an assertion at the exact edge value.
    • A removed function call survives -> no test checks that side effect; assert the side effect.
    • A negated condition survives -> the two branches are indistinguishable to the suite; assert the differing outcome of each branch.
    • A return value replaced with a constant survives -> the return is unchecked; assert it.
  5. Triage equivalent mutants. Some mutants cannot change observable behavior (a change in dead code, i++ vs ++i in isolation). Distinguishing them is undecidable in general - mark them ignored in the tool's config rather than chasing 100%.
  6. Set a meaningful floor on the targeted modules only (e.g. 70-80% mutation score), where score = killed / (total non-equivalent mutants). Never set one global threshold.

Quality bar

  • Every reported survivor maps to one concrete, named assertion a developer can write - no "add more tests."
  • Mutation runs are scoped (diff/incremental in CI, full sweep nightly); no PR blocks on a full-repo run.
  • Equivalent mutants are explicitly ignored, not silently inflating or deflating the score.
  • The score is presented as a quality signal for already-covered code, never as a coverage substitute.

Do NOT

  • Do NOT block every PR on a full-repo mutation run - it reruns the suite per mutant and will stall the pipeline.
  • Do NOT chase a 100% mutation score; equivalent mutants make it unreachable and the marginal mutants are noise.
  • Do NOT run mutation testing on generated code, DTOs, or glue - spend the compute where a silent failure hurts.
  • Do NOT use a single global threshold; floors belong on critical modules.
  • Do NOT treat mutation testing as a substitute for deciding what to test. It measures assertion strength on existing code; a missing feature has no code to mutate. To find untested paths and inputs, use coverage-gap-finder.

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.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.