werkcrappit computes how well other projects' tests catch changes, but nobody measured its own tests that way.
Non-Goals
A gate: no maxMutationCrap yet; the first reports decide where a limit belongs.
The Gradle plugin module: its five classes are tested by the functional tests, which start real Gradle builds with PIT, minutes per mutant.
The Solution
werkcrappit-pit/build.gradle.kts applies info.solidsoft.pitest 1.19.0 and the released Gradle plugin de.javagil.werkcrappit 0.16.0.
PIT 1.30.0 with pitest-junit5-plugin 1.2.3 runs the unit tests; the history plugin keeps incremental results in .pitest/, outside build/.
The Gradle plugin adds werkcrappit-pit to PIT's classpath by its coordinates, which are this project's; Gradle takes this project for them, whatever the version, and no substitution rule changes that.
So werkcrappit measures itself with the listener of the same commit, and pitest depends on jar, which the PIT plugin does not know is needed.
-Dwerkcrappit.version reaches PIT's minions too: VersionConsistencyTest needs it, and a test failing without mutation aborts the run.
settings.gradle.kts: the Maven registry of git.javagil.de for the Gradle plugin.
.werkator.yml: the definition mutation, nightly at 03:00 UTC on main after new commits, the slot after Werkator's own mutation build on mih09; timeout: 30m; it cleans only its own reports, as main's worktree is shared.
Version 0.16.1.
Open Questions
The first run starts right after the merge, as the day's 03:00 slot is past; it takes some minutes.
Attachments
The local full run of 2026-10-03
6 min 19 s with 2 threads: 836 mutants, 688 killed (82 %), 40 without coverage; 600 methods, 271 scored, the highest values
Levelization.breakCycles 22.9
RealLines.count 20.1
Json.compact 16.1
Gate.judge 16.0
MethodEvaluator.evaluate 16
The run also found a bug: 0.15.0's progress lines never appeared, because PIT's start time is System.nanoTime(); fixed in 0.15.2 (PR#28).
## The Problem
werkcrappit computes how well other projects' tests catch changes, but nobody measured its own tests that way.
## Non-Goals
- A gate: no `maxMutationCrap` yet; the first reports decide where a limit belongs.
- The Gradle plugin module: its five classes are tested by the functional tests, which start real Gradle builds with PIT, minutes per mutant.
## The Solution
- `werkcrappit-pit/build.gradle.kts` applies `info.solidsoft.pitest` 1.19.0 and the released Gradle plugin `de.javagil.werkcrappit` 0.16.0.
- PIT 1.30.0 with `pitest-junit5-plugin` 1.2.3 runs the unit tests; the history plugin keeps incremental results in `.pitest/`, outside `build/`.
- The Gradle plugin adds `werkcrappit-pit` to PIT's classpath by its coordinates, which are this project's; Gradle takes this project for them, whatever the version, and no substitution rule changes that.
So werkcrappit measures itself with the listener of the same commit, and `pitest` depends on `jar`, which the PIT plugin does not know is needed.
- `-Dwerkcrappit.version` reaches PIT's minions too: `VersionConsistencyTest` needs it, and a test failing without mutation aborts the run.
- `settings.gradle.kts`: the Maven registry of git.javagil.de for the Gradle plugin.
- `.werkator.yml`: the definition `mutation`, nightly at 03:00 UTC on `main` after new commits, the slot after Werkator's own mutation build on mih09; `timeout: 30m`; it cleans only its own reports, as `main`'s worktree is shared.
- Version 0.16.1.
## Open Questions
- The first run starts right after the merge, as the day's 03:00 slot is past; it takes some minutes.
## Attachments
### The local full run of 2026-10-03
6 min 19 s with 2 threads: 836 mutants, 688 killed (82 %), 40 without coverage; 600 methods, 271 scored, the highest values
- `Levelization.breakCycles` 22.9
- `RealLines.count` 20.1
- `Json.compact` 16.1
- `Gate.judge` 16.0
- `MethodEvaluator.evaluate` 16
The run also found a bug: 0.15.0's progress lines never appeared, because PIT's start time is `System.nanoTime()`; fixed in 0.15.2 (PR#28).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The Problem
werkcrappit computes how well other projects' tests catch changes, but nobody measured its own tests that way.
Non-Goals
maxMutationCrapyet; the first reports decide where a limit belongs.The Solution
werkcrappit-pit/build.gradle.ktsappliesinfo.solidsoft.pitest1.19.0 and the released Gradle pluginde.javagil.werkcrappit0.16.0.pitest-junit5-plugin1.2.3 runs the unit tests; the history plugin keeps incremental results in.pitest/, outsidebuild/.werkcrappit-pitto PIT's classpath by its coordinates, which are this project's; Gradle takes this project for them, whatever the version, and no substitution rule changes that.So werkcrappit measures itself with the listener of the same commit, and
pitestdepends onjar, which the PIT plugin does not know is needed.-Dwerkcrappit.versionreaches PIT's minions too:VersionConsistencyTestneeds it, and a test failing without mutation aborts the run.settings.gradle.kts: the Maven registry of git.javagil.de for the Gradle plugin..werkator.yml: the definitionmutation, nightly at 03:00 UTC onmainafter new commits, the slot after Werkator's own mutation build on mih09;timeout: 30m; it cleans only its own reports, asmain's worktree is shared.Open Questions
Attachments
The local full run of 2026-10-03
6 min 19 s with 2 threads: 836 mutants, 688 killed (82 %), 40 without coverage; 600 methods, 271 scored, the highest values
Levelization.breakCycles22.9RealLines.count20.1Json.compact16.1Gate.judge16.0MethodEvaluator.evaluate16The run also found a bug: 0.15.0's progress lines never appeared, because PIT's start time is
System.nanoTime(); fixed in 0.15.2 (PR#28).🤖 Generated with Claude Code