PIT (Pitest)

Visit Website

Introduction

PIT, also called Pitest, describes itself as a state-of-the-art mutation testing system for Java and the JVM. It was created by Henry Coles and is maintained on GitHub under the Apache-2.0 licence, with frequent releases; version 1.30.2 was published on 5 November 2026.

Mutation testing answers a question coverage cannot: would my tests notice if this code were wrong? PIT makes small changes (mutants) to your compiled bytecode, such as flipping a condition, changing a return value or removing a method call, then runs the tests that cover each changed line. If a test fails, the mutant is killed; if all tests still pass, the mutant survived, which points to missing or weak assertions.

Doing this naively is slow, so PIT focuses on speed: it works on bytecode rather than recompiling source, uses coverage data to run only the tests that exercise each mutant, and supports incremental analysis so unchanged code is not re-analysed. The changelog shows ongoing work on newer Java versions (for example fixes for Java 25 mutators), SBOM publication via CycloneDX, and support for JSpecify.

How it compares: PIT is to the JVM what Stryker is to JavaScript and .NET, mutmut to Python and Infection to PHP. Compared with JaCoCo coverage, the mutation score is a stronger, though more expensive, signal of test quality. An Arcmutate commercial extension set exists for Kotlin support and git-aware analysis; the core PIT tool is free.

In the quality loop, PIT is used during development to strengthen unit tests and in scheduled or pull-request jobs to stop test quality from slipping.

The source code is at hcoles/pitest on GitHub under the Apache-2.0 licence, with about 1,900 stars; the most recent commit was on 5 November 2026.

Reading a PIT report is straightforward. Each source line is shaded by coverage and mutation result, and expanding a line lists the mutants created there, such as “negated conditional” or “replaced return value with null”, along with whether they were killed, survived, timed out or had no coverage. A surviving “changed conditional boundary” mutant, for example, usually means there is no test at the exact boundary value (such as >= versus >). Teams often add a mutation-score threshold to CI only for selected packages, and run full analysis nightly, which balances feedback speed against runtime.

Features

1. Bytecode mutation: Generates mutants directly in bytecode for speed.
2. Mutator groups: Default and stronger mutator sets covering conditionals, maths, return values, void method calls and more.
3. Targeted test execution: Uses coverage data so each mutant runs only against tests that reach it.
4. Incremental analysis: History files skip re-analysing unchanged code between runs.
5. Reports: HTML reports with line-by-line surviving mutants, plus XML and other formats.
6. Build plugins: Maven plugin and a community Gradle plugin, plus support for Ant and the command line.
7. JUnit 5 and TestNG: Supported through plugins, alongside JUnit 4.
8. Thresholds: Fail builds below a mutation score or coverage threshold.

Pros

1. Shows weak tests: Surviving mutants point to exact lines where assertions are missing.
2. Fast for mutation testing: Bytecode mutation and targeted test runs keep runtimes manageable.
3. Free to use: Open source under the Apache-2.0 licence, so the core tool costs nothing to use.
4. Actively maintained: The repository had commits as recent as 5 November 2026.

Cons

1. Still slow on big codebases: Full runs can take a long time; scope runs to changed code or key modules.
2. Equivalent mutants: Some surviving mutants cannot be killed because they do not change behaviour.
3. Kotlin support: Idiomatic Kotlin support relies on extensions; plain PIT targets Java bytecode semantics.
4. Learning curve: Interpreting reports and choosing mutators takes some experience.

Usage and Links (Example)

Run PIT with Maven (JUnit 5 needs the plugin dependency):

<plugin>
  <groupId>org.pitest</groupId>
  <artifactId>pitest-maven</artifactId>
  <version>1.30.2</version>
  <dependencies>
    <dependency>
      <groupId>org.pitest</groupId>
      <artifactId>pitest-junit5-plugin</artifactId>
      <version><!-- current version from pitest.org --></version>
    </dependency>
  </dependencies>
  <configuration>
    <targetClasses><param>com.example.pricing.*</param></targetClasses>
    <mutationThreshold>70</mutationThreshold>
  </configuration>
</plugin>

mvn test-compile org.pitest:pitest-maven:mutationCoverage

Open target/pit-reports/index.html to see killed and surviving mutants per line. Check the PIT site for the current JUnit 5 plugin version.

Practical tips:

1. Start with one important module, not the whole codebase.
2. Enable history files so repeated runs only analyse what changed.
3. Treat surviving mutants as prompts for better assertions, not as a number to game.

Resources:

• PIT (Pitest) website
• GitHub repository
• Quickstart

Pricing

PIT (Pitest) is free and open source under the Apache-2.0 licence.

Recommended for?

1. Java teams who want evidence that their tests catch bugs.
2. Teams with high coverage but low confidence, where coverage numbers hide weak assertions.
3. Critical domains such as pricing, billing and security logic.
4. Not a fit as a per-commit gate on very large codebases without scoping or incremental analysis.

Conclusion

PIT is the leading mutation testing tool for the JVM, fast enough for real projects thanks to bytecode mutation and targeted test execution.

Use it alongside coverage: JaCoCo shows what code runs, and PIT shows whether your tests would notice if that code were wrong.