Configure Mutation Testing for Robust Code

This skill configures and implements mutation testing across languages and frameworks - PIT/PITest for Java, Stryker for JavaScript/TypeScript/C#, and other mutation testing tools - to maximize how effectively they surface weaknesses in a test suite. Its core principle is that mutation testing measures test quality, not just coverage: high line coverage doesn't guarantee effective tests, so configuration should target critical business logic paths, complex conditional statements, and high-risk code areas while balancing execution time against thoroughness. It applies a selective mutation strategy - not mutating all code equally, but weighting by code complexity and criticality, recent changes and bug history, the performance cost of mutation testing, and the team's actual capacity to fix surviving mutants.

For PITest it configures both Maven and Gradle builds: target and excluded classes/tests, mutator sets, mutation and coverage thresholds, timeout factor, thread count, and output formats. A representative Maven setup:

<plugin>
    <groupId>org.pitest</groupId>
    <artifactId>pitest-maven</artifactId>
    <version>1.15.0</version>
    <configuration>
        <targetClasses>
            <param>com.example.business.*</param>
            <param>com.example.domain.*</param>
        </targetClasses>
        <targetTests>
            <param>com.example.*Test</param>
        </targetTests>
        <excludedClasses>
            <param>com.example.config.*</param>
            <param>com.example.dto.*</param>
        </excludedClasses>
        <mutators>
            <mutator>STRONGER</mutator>
        </mutators>
        <mutationThreshold>80</mutationThreshold>
        <coverageThreshold>70</coverageThreshold>
        <timeoutFactor>1.25</timeoutFactor>
        <threads>4</threads>
        <outputFormats>
            <outputFormat>HTML</outputFormat>
            <outputFormat>XML</outputFormat>
        </outputFormats>
    </configuration>
</plugin>

For Stryker it configures stryker.conf.json - package manager, reporters, test runner, coverage analysis mode, mutate/ignore glob patterns, high/low/break score thresholds, timeout, and concurrent test runner limits. Advanced strategies include incremental mutation testing (running PITest with Git-change detection or Stryker's --incremental flag, so only changed code gets re-mutated) and custom mutator groups (conditionals boundary, increments, math, negate conditionals, return values) to target specific mutation operators.

For performance it recommends thread counts at CPU cores minus one, a timeout factor between 1.1-1.5, and selective testing that excludes integration/E2E test classes from the mutation run. For CI/CD it wires mutation testing into a quality gate that fails the build below a score threshold, and integrates reporting with SonarQube (via the PITest plugin) or Stryker Dashboard for trend tracking.

Use it when you need to actually measure test suite effectiveness, not just line coverage - especially for critical business logic where surviving mutants indicate real gaps. It sets pragmatic targets rather than an absolute bar: 60-70% mutation score for legacy code, 80%+ for new critical logic, with the caveat that the goal is improving test quality, not chasing the score itself. It also names three ways to legitimately handle survivors without over-testing: document and exclude truly equivalent mutants, adjust timeout factor or exclude infinite-loop-prone timeout mutants, and only write new tests for valid survivors.

Input is the target codebase's build configuration (Maven, Gradle, or npm/Stryker) and its existing test suite. Output is a working mutation testing configuration plus CI quality-gate wiring, dashboard/report integration, and a maintenance plan: full mutation runs weekly on CI, incremental runs on pull requests, and periodic review of exclusion patterns and execution time.

It integrates with Maven and Gradle build tooling for Java (PITest), npm/Jest for JavaScript/TypeScript (Stryker), Git for incremental/changed-code mutation, GitHub Actions for CI quality gates, and SonarQube or Stryker Dashboard for reporting.

Engineering teams who need to verify their test suite actually catches bugs, not just executes lines - setting up and tuning PITest or Stryker, wiring results into CI quality gates, and maintaining the configuration over time.