miandmhoennig
0f21718e32
werkator build succeeded after 00:32
Step 2 of 8 from section 8.3 of the specification. - Tool-free core `de.hoennig.werkcrappit.pit.core`: `MethodEvaluator`, `StrictV1` (table of 5.2), `MutationCrap` as an exact fraction with `exceeds(limit)`. - Non-numeric states with machine-readable reasons; invalid input rejected with a concrete reason. - Features 01 and 02 copied from the specification into `docs/features/`, parsed by the Gherkin parser in a test; `docs/acceptance-test-map.md` maps MC-001 to MC-007. - The PIT run still writes the step-1 report without a score (report contract: step 5). CI on werkator.javagil.de: green (49 s). PR-doc: `docs/prs/2026-10-01-PR#3-metric-core.md` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: mhoennig <michael@hoennig.de> Reviewed-on: #3
56 lines
2.7 KiB
Gherkin
56 lines
2.7 KiB
Gherkin
# language: de
|
|
Funktionalität: Mutation-CRAP pro JVM-Methode berechnen
|
|
Als Entwickler möchte ich Komplexität und Mutationsergebnisse gemeinsam sehen,
|
|
damit ich Methoden für eine genauere Prüfung priorisieren kann.
|
|
|
|
@MC-001
|
|
Szenariogrundriss: Der Score entspricht der definierten Formel
|
|
Angenommen eine Methode hat die JaCoCo-Komplexität <komplexitaet>
|
|
Und es liegen <killed> KILLED-, <survived> SURVIVED- und <uncovered> NO_COVERAGE-Ergebnisse vor
|
|
Und es liegen keine weiteren Mutationsergebnisse vor
|
|
Wenn die Methode mit der Policy "strict-v1" ausgewertet wird
|
|
Dann ist ihr Zustand "SCORED"
|
|
Und ihr Mutation Score ist <mutationScore>
|
|
Und ihr Mutation-CRAP ist <crap>
|
|
|
|
Beispiele:
|
|
| komplexitaet | killed | survived | uncovered | mutationScore | crap |
|
|
| 1 | 0 | 1 | 0 | 0 | 2 |
|
|
| 10 | 0 | 10 | 0 | 0 | 110 |
|
|
| 10 | 5 | 5 | 0 | 0.5 | 22.5 |
|
|
| 10 | 8 | 2 | 0 | 0.8 | 10.8 |
|
|
| 10 | 10 | 0 | 0 | 1 | 10 |
|
|
| 30 | 10 | 0 | 0 | 1 | 30 |
|
|
|
|
@MC-002
|
|
Szenario: Ausschließlich nicht wertbare Mutanten ergeben keinen Score
|
|
Angenommen eine Methode hat die JaCoCo-Komplexität 4
|
|
Und ihre einzigen Ergebnisse sind 2 EQUIVALENT und 1 NON_VIABLE
|
|
Wenn die Methode mit der Policy "strict-v1" ausgewertet wird
|
|
Dann ist ihr Zustand "NO_ELIGIBLE_MUTANTS"
|
|
Und ihr Mutation Score und ihr Mutation-CRAP sind null
|
|
Und ihre Komplexität und ihre Rohzähler bleiben im Report sichtbar
|
|
|
|
@MC-003
|
|
Szenario: Eine Methode ohne Ergebnisse wird nicht als gut getestet dargestellt
|
|
Angenommen eine Methode gehört zum ausgewerteten Methodeninventar
|
|
Und sie hat die JaCoCo-Komplexität 12
|
|
Und es liegt kein Mutationsergebnis für diese Methode vor
|
|
Wenn der Report erstellt wird
|
|
Dann ist ihr Zustand "NO_MUTATION_RESULTS"
|
|
Und ihr Mutation Score und ihr Mutation-CRAP sind null
|
|
Und der Report behauptet weder null noch vollständige Testwirksamkeit
|
|
|
|
@MC-004
|
|
Szenariogrundriss: Ungültige Recheneingaben werden nicht kaschiert
|
|
Angenommen eine Recheneingabe enthält <fehler>
|
|
Wenn eine numerische Metrik daraus berechnet werden soll
|
|
Dann wird die ungültige Eingabe mit einem konkreten Grund zurückgewiesen
|
|
Und es wird kein gültiger Methodenwert erzeugt
|
|
|
|
Beispiele:
|
|
| fehler |
|
|
| eine negative Anzahl getöteter Mutanten |
|
|
| einen negativen Komplexitätswert |
|
|
| Komplexität 0 für eine numerisch bewertete Methode |
|