mcpField
M
mutation-testing

mutation-testing

github.com/amplicodeTesting & quality134146 installsUpdated 8w ago
Repository

About mutation-testing

A skill for configuring and running PIT mutation testing in a project, then reporting and recording the result. It guides build setup, mutation exclusions, test execution, and project-specific configuration notes.

Key features

  1. 01Check existing PIT configuration
  2. 02Configure PIT in the build
  3. 03Adjust mutation exclusions
  4. 04Run PIT and report the score
  5. 05Record resolved run configuration

Use cases

  1. 01Add PIT to a project build
  2. 02Change mutation exclusions or target classes
  3. 03Run mutation testing and report its score

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/amplicode/spring-skills --skill mutation-testing

After installing, type/mutation-testingin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
add-exclusion.md
configuration.md
exclusions.md
junit6.md
report.md
usage.md
scripts/
summarize_mutations.py

Details

From the project README

Mutation testing

Steps

Start by reading this skill's own pitest entry for THIS project (type: project) — the checks below are built on it. A missing entry is not an error; it means nothing has been recorded yet.

Then work through the steps in order. Each carries a check: when the check fires the step is already done — skip it and move on. Load a step's reference only if you actually run that step, so there is context left for the PIT output.

1. Configure PIT in the build

Skip if PIT is already configured. Two signals say so — stop at the first hit:

  • The entry describes a configuration for this project. That is enough: skip the step, and do not spend a command confirming what the entry just said.

  • No entry — then ask the build file:

    grep -n "info.solidsoft.pitest" build.gradle build.gradle.kts 2>/dev/null

Otherwise follow references/configuration.md, which applies the exclusions as part of the setup.

If step 3 then fails with Task 'pitest' not found, the entry was stale: say so, run this step after all, and continue.

2. Adjust what gets mutated

Skip if the request has nothing to do with the exclusions or targetClasses.

Otherwise follow references/add-exclusion.md. It answers a question as well as it applies a change — when the request is only a question, stop after judging the candidate and leave the build alone.

3. Run PIT and report the score

Skip if the user asked only to wire PIT into the build, or only for advice on what to exclude — then say a run is available and stop there.

Otherwise follow references/usage.md.

4. Record what was resolved

Skip if the entry already describes what the run actually used.

Otherwise write or update pitest in the shape references/configuration.md step 5 defines. This is what lets step 1 be skipped next time, so it is not optional bookkeeping — dropping it makes the next run pay for the version probing and compatibility checks all over again.

Comments

Markdown supported