miandmhoennig
d8e2246c3b
werkator build succeeded after 00:35
Step 5 of 8 from section 8.3 of the specification. - `mutation-crap.json`, schema version 1 (JSON Schema 2020-12, shipped in the JAR): definition, provenance (incl. origin + SHA-256 per class file), configuration, scope, summary, methods; `null` for undefined values, exact fraction `mutationCrapExact` for the gate; deterministic, no timestamps. - `mutation-crap.md` and a short console summary, written from the same data. - `runStart()` replaces both reports with a RUNNING marker, so an aborted run never leaves an older finished report behind. - Options via PIT's `pluginConfiguration` with prefix `werkcrappit.` (`analysisContext`, `excludeClasses`, `excludeMethods`); unknown own keys stop the run. Reporting exclusions = MC-013. - ADR 0004, feature 05; MC-013, MC-018, MC-026 passing; MC-019 to MC-025 open for step 6. Found on the way: the Kotlin DSL cannot assign the PIT plugin's `pluginConfiguration` with `=`; README shows `putAll`. CI on werkator.javagil.de: green (44 s), 97 unit and 13 functional tests. PR-doc: `docs/prs/2026-10-01-PR#6-reports.md` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: mhoennig <michael@hoennig.de> Reviewed-on: #6
90 lines
4.1 KiB
Gherkin
90 lines
4.1 KiB
Gherkin
# language: de
|
|
Funktionalität: Nachvollziehbare Reports und ein bewusst aktiviertes Build-Gate liefern
|
|
Als CI-Nutzer möchte ich hohe Scores und Analyseprobleme unterscheiden,
|
|
ohne fehlende Daten mit guter Qualität zu verwechseln.
|
|
|
|
@MC-019
|
|
Szenario: Der Standardmodus erstellt Reports ohne Score-bedingten Build-Abbruch
|
|
Angenommen die Analyse ist regulär abgeschlossen
|
|
Und eine Methode hat Mutation-CRAP 110
|
|
Und es ist kein Score-Gate aktiviert
|
|
Wenn das Ergebnis ausgegeben wird
|
|
Dann bleibt der Build wegen dieses Scores erfolgreich
|
|
Und der hohe Wert ist im Report sichtbar
|
|
|
|
@MC-020
|
|
Szenariogrundriss: Nur eine echte Überschreitung verletzt den Grenzwert
|
|
Angenommen eine Methode hat den gültigen Mutation-CRAP-Wert <score>
|
|
Und ein Score-Gate mit Grenzwert 30 ist aktiviert
|
|
Und es liegen keine weiteren Verstöße oder Analyseprobleme vor
|
|
Wenn das Gate ausgewertet wird
|
|
Dann ist das Build-Ergebnis <ergebnis>
|
|
|
|
Beispiele:
|
|
| score | ergebnis |
|
|
| 29 | erfolgreich |
|
|
| 30 | erfolgreich |
|
|
| 31 | fehlgeschlagen |
|
|
|
|
@MC-021
|
|
Szenario: Anzeigerundung beeinflusst das Gate nicht
|
|
Angenommen eine Methode hat Komplexität 10, 79 KILLED- und 21 SURVIVED-Ergebnisse
|
|
Und ihr exakter Mutation-CRAP-Wert beträgt 10.9261
|
|
Und für die Anzeige wird auf eine Nachkommastelle gerundet
|
|
Und der aktivierte Grenzwert beträgt 10.92
|
|
Wenn das Gate ausgewertet wird
|
|
Dann scheitert es wegen der tatsächlichen Überschreitung
|
|
Und der gerundete Anzeigewert 10.9 wird nicht für den Vergleich verwendet
|
|
|
|
@MC-022
|
|
Szenariogrundriss: Ein striktes Gate kann Analyseprobleme nicht als Erfolg werten
|
|
Angenommen alle numerisch bewerteten Methoden liegen unter ihrem Grenzwert
|
|
Aber es besteht <problem>
|
|
Wenn das aktivierte strikte Gate ausgewertet wird
|
|
Dann scheitert es mit einem konkreten Analysefehler
|
|
Und der Fehler wird nicht als schlechte Testqualität bezeichnet
|
|
|
|
Beispiele:
|
|
| problem |
|
|
| ein INCONCLUSIVE-Ergebnis |
|
|
| unerwartet fehlende Methodenkomplexität |
|
|
| ein unerwartet unvollständig inventarisierter Scope |
|
|
| ein fehlender oder unlesbarer aktueller Report |
|
|
| eine nicht unterstützte Report-Schemaversion |
|
|
|
|
@MC-023
|
|
Szenario: Eine leere Auswertung wird nicht stillschweigend grün
|
|
Angenommen ein Score-Gate ist aktiviert
|
|
Und im ausgewählten Scope ist keine einzige Methode numerisch bewertbar
|
|
Und leere Auswertungen sind nicht ausdrücklich erlaubt
|
|
Wenn das Gate ausgewertet wird
|
|
Dann scheitert es mit dem Hinweis auf eine leere Auswertung
|
|
|
|
@MC-024
|
|
Szenario: Ein absichtlich leeres Modul kann ausdrücklich erlaubt werden
|
|
Angenommen die Analyse eines Moduls ist regulär abgeschlossen
|
|
Und es gibt keine numerisch bewertbaren Methoden und keine Analysefehler
|
|
Und leere Auswertungen sind ausdrücklich erlaubt
|
|
Wenn das aktivierte Gate ausgewertet wird
|
|
Dann scheitert es nicht allein wegen der leeren Auswertung
|
|
Und der Report bezeichnet das Modul weiterhin als unbewertet
|
|
|
|
@MC-025
|
|
Szenario: Nach einer Grenzwertverletzung bleiben Reports verfügbar
|
|
Angenommen PIT und alle aktivierten Reporter sind regulär abgeschlossen
|
|
Und ein Methodenwert verletzt den aktivierten Grenzwert
|
|
Wenn der nachgeschaltete Gate-Task ausgeführt wird
|
|
Dann schlägt der Build fehl
|
|
Und der JSON-Report bleibt vollständig und schemakonform lesbar
|
|
Und der Markdown-Report und die normalen PIT-Reports bleiben verfügbar
|
|
|
|
@MC-026
|
|
Szenario: Maschinenlesbare Werte sind eindeutig und nachrechenbar
|
|
Angenommen eine Auswertung enthält bewertete und unbewertete Methoden
|
|
Wenn der JSON-Report geschrieben wird
|
|
Dann enthält er Metrikversion, Policykennung, Toolversionen und Analysescope
|
|
Und er enthält die verwendeten Methodenidentitäten und Status-Rohzähler
|
|
Und nicht definierte numerische Werte werden als null geschrieben
|
|
Und kein Feld enthält NaN oder Infinity
|
|
Und der Report entspricht seinem versionierten JSON-Schema
|