miandmhoennig
78a2873932
werkator build succeeded after 01:17
Step 6 of 8 from section 8.3 of the specification.
- Gradle plugin `de.hoennig.werkcrappit` on top of `info.solidsoft.pitest`: werkcrappit-pit on PIT's tool classpath, output format added (keeping configured formats, else PIT's HTML), `werkcrappit { … }` options into PIT's pluginConfiguration (keeping other plugins' entries).
- `mutationCrapCheck` depends on `pitest`, not part of `check`; judges the report with the shared `Gate` (in werkcrappit-pit): exact fraction, equality passes, analysis errors kept apart from limit violations, empty evaluation fails unless `allowEmpty`.
- Functional tests in real builds: limits 4 / 3.3333 / 3.3334 on an exact 10/3 with PIT UP-TO-DATE, failing PIT never reaches the gate, unit + integration test source sets in one PIT run, two subprojects in parallel.
- Found by the first functional run: the PIT plugin's task properties stay *missing* unless configured, and add/put on them keeps them missing — the plugin derives the values from the PIT extension (ADR 0005).
- ADR 0005, feature 06; MC-019..MC-028, MC-030, MC-031 passing; MC-029 Groovy DSL open for step 8.
CI on werkator.javagil.de: green (89 s).
PR-doc: `docs/prs/2026-10-01-PR#7-gradle-gate.md`
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: mhoennig <michael@hoennig.de>
Reviewed-on: #7
55 lines
2.8 KiB
Gherkin
55 lines
2.8 KiB
Gherkin
# language: de
|
|
Funktionalität: Das PIT-Plugin in Gradle-Projekten einsetzen
|
|
Als Java-Entwickler möchte ich meine vorhandene PIT-Konfiguration weiterverwenden,
|
|
statt Mutationstests für die neue Metrik separat orchestrieren zu müssen.
|
|
|
|
@MC-027
|
|
Szenario: Unit- und Integrationstests bleiben über PIT konfigurierbar
|
|
Angenommen ein Java-Projekt verwendet JUnit Jupiter
|
|
Und seine PIT-Konfiguration berücksichtigt Unit- und Integrationstest-Source-Sets
|
|
Und das Mutation-CRAP-Plugin ist aktiviert
|
|
Wenn der dokumentierte Mutation-CRAP-Workflow gestartet wird
|
|
Dann wird genau eine PIT-Analyse für diese Konfiguration angefordert
|
|
Und deren Ergebnisse einschließlich der einbezogenen Integrationstests werden verwendet
|
|
Und das Plugin startet keine zusätzlichen Gradle-Testtasks zur Komplexitätsermittlung
|
|
|
|
@MC-028
|
|
Szenario: Gleiche Methodenidentitäten aus zwei Teilprojekten bleiben getrennt
|
|
Angenommen zwei Gradle-Teilprojekte enthalten jeweils dieselbe JVM-Klasse und Methodensignatur
|
|
Und die beiden Methoden haben unterschiedliche Auswertungsergebnisse
|
|
Wenn beide Teilprojekte parallel ihre PIT-Analyse durchführen
|
|
Dann erhält jedes Teilprojekt seinen eigenen Report
|
|
Und die Einträge tragen unterscheidbare Analysekontexte
|
|
Und keine Ergebnisse oder Dateien werden gegenseitig überschrieben
|
|
|
|
@MC-029
|
|
Szenariogrundriss: Ein Anwender konsumiert das tatsächlich gepackte Plugin
|
|
Angenommen das Plugin wurde in ein isoliertes lokales Test-Artefakt-Repository publiziert
|
|
Und ein separates Anwenderprojekt verwendet <dsl>
|
|
Und es kennt keine Klassenverzeichnisse aus dem Plugin-Entwicklungsbuild
|
|
Wenn der dokumentierte Gradle/PIT-Aufruf gestartet wird
|
|
Dann wird die Service-Factory aus dem Plugin-JAR gefunden
|
|
Und alle erforderlichen Runtime-Abhängigkeiten werden geladen
|
|
Und ein Report mit echten Java-Methodenwerten entsteht
|
|
|
|
Beispiele:
|
|
| dsl |
|
|
| Kotlin DSL |
|
|
| Groovy DSL |
|
|
|
|
@MC-030
|
|
Szenario: Ein geänderter Grenzwert benötigt keine erneuten Mutationstests
|
|
Angenommen ein für unveränderte Analyseinputs gültiger PIT-Report liegt vor
|
|
Und die zugehörige PIT-Task kann korrekt als aktuell behandelt werden
|
|
Wenn nur der Gate-Grenzwert geändert und der Gate-Task ausgeführt wird
|
|
Dann wird die Gate-Entscheidung mit dem neuen Grenzwert neu berechnet
|
|
Und dafür wird keine zusätzliche PIT-Analyse gestartet
|
|
|
|
@MC-031
|
|
Szenario: Ein gescheiterter PIT-Lauf darf keinen alten Report als Erfolg verwenden
|
|
Angenommen ein erfolgreicher Report aus einem früheren Lauf existiert
|
|
Und die aktuelle PIT-Analyse scheitert vor dem regulären Abschluss
|
|
Wenn der dokumentierte CI-Workflow ausgeführt wird
|
|
Dann bleibt der Build fehlgeschlagen
|
|
Und es wird kein aktueller Gate-Erfolg aus dem alten Report abgeleitet
|