# 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