ViachaslauStrelnikau/agent-skills

Java-Tester

Betriebsmodell

Fügen Sie Tests hinzu, die das Vertrauen auf der niedrigsten praktischen Ebene der Testpyramide erhöhen. Bevorzugen Sie viele schnelle Unit-Tests, weniger Integrations- oder Vertragstests und eine sehr kleine Anzahl von End-to-End-Tests für kritische Abläufe.

Beginnen Sie mit dem Lesen des Produktionscodes, vorhandener Tests, Build-Dateien und CI-Konventionen. Behalten Sie den Teststil des Projekts bei, es sei denn, er ist offensichtlich schwach oder inkonsistent. Führen Sie keine neue Testbibliothek ein, wenn das Projekt bereits eine gleichwertige Lösung hat.

Verwenden Sie Context7 für aktuelle Dokumentation, bevor Sie librariespezifische Syntax, Konfiguration, Annotationen, Erweiterungen oder Abhängigkeitsversionen für JUnit, Mockito, AssertJ, Spring Boot Test, Testcontainers, REST Assured, Pact, WireMock, Maven, Gradle oder andere Java-Testwerkzeuge hinzufügen oder ändern. Wenn Context7 nicht verfügbar ist oder die Bibliothek nicht auflösen kann, verwenden Sie die offizielle Projektdokumentation; raten Sie keine versionsspezifischen Details.

Wählen Sie den Aufgabenmodus

• Für die Implementierung: Identifizieren Sie das geänderte Verhalten, fügen Sie den kleinsten sinnvollen Satz von Tests hinzu und überprüfen Sie sie.
• Für die Überprüfung: Untersuchen Sie die vorhandene Suite und berichten Sie über Korrektheit, fehlende Risikoabdeckung, Anfälligkeit, Duplizierung, Isolationsprobleme und Laufzeitkosten. Nehmen Sie keine Änderungen vor, es sei denn, der Benutzer fordert diese an.
• Für das Debugging: Reproduzieren Sie den Fehler eng, klassifizieren Sie seine Ursache und ändern Sie Tests oder Produktionscode nur innerhalb des vom Benutzer angeforderten Umfangs.
• Für die Organisation oder CI-Planung: Inventarisieren Sie Testtypen, Quellsets, Laufzeit, Abhängigkeiten und aktuelle Pipeline-Stufen, bevor Sie Platzierung, Auswahl, Parallelisierung oder Caching empfehlen.

Arbeitsablauf

1. Identifizieren Sie das zu schützende Verhalten.

   • Finden Sie öffentliche APIs, Servicemethoden, Domänenregeln, Persistenzgrenzen, Nachrichtenhandler, Controller, Scheduler und Fehlerpfade, die von der Anfrage betroffen sind.
   • Bevorzugen Sie Verhaltensassertionen gegenüber Implementierungsassertionen.
   • Behandeln Sie private Methoden als Implementierungsdetails; testen Sie sie durch öffentliches Verhalten oder extrahieren Sie einen fokussierten Kollaborateur, wenn die private Logik komplex ist.

2. Wählen Sie die niedrigste sinnvolle Testebene.

   • Verwenden Sie Unit-Tests für reine Domänenlogik, Verzweigungen, Validierungen, Abbildungen und Kollaborateur-Orchestrierung, die ohne reale E/A getestet werden können.
   • Verwenden Sie Slice- oder Integrationstests für Framework-Verdrahtung, Persistenzabfragen, Datenmigrationen, Serialisierung, Transaktionen, HTTP-Routing, Sicherheitsfilter und externe Grenzadapter.
   • Verwenden Sie Vertragstests, wenn eine Dienstgrenze von mehreren Teams oder unabhängigen Bereitstellungseinheiten besessen wird.
   • Verwenden Sie End-to-End-Tests nur für Kernabläufe, die durch niedrigere Tests nicht vertrauenswürdig sind.

3. Implementieren Sie fokussierte Abdeckung.

   • Decken Sie Happy Paths, Grenzfälle, Grenzwerte, ungültige Eingaben, Fehler, Ergebnisse der Sicherheitsautorisierung, Datenbankzustandsänderungen und Regressionen ab.
   • Verwenden Sie parametrisierte Tests für wiederholte Eingabe-/Ausgabebeispiele.
   • Halten Sie einen Grund zum Scheitern pro Test. Benennen Sie Tests nach Verhalten und erwartetem Ergebnis.
   • Verwenden Sie deterministische Daten. Vermeiden Sie Sleeps, Annahmen über die Wanduhrzeit, zufällige Reihenfolge, Netzwerkabhängigkeiten und gemeinsamen veränderlichen Zustand.

4. Halten Sie Tests wartbar.

   • Verwenden Sie Arrange/Act/Assert oder Given/When/Then konsequent.
   • Erstellen Sie Builder, Fixtures oder Test Data Mothers nur, wenn wiederholtes Setup die Absicht verschleiert.
   • Halten Sie Mocks an Prozessgrenzen oder wirklich umständlichen Kollaborateuren. Mocken Sie keine Wertobjekte, Sammlungen oder triviale Domänenlogik.
   • Vermeiden Sie die Überprüfung jeder Interaktion. Überprüfen Sie zuerst Ergebnisse; überprüfen Sie Interaktionen nur, wenn die Interaktion das Verhalten ist.

5. Überprüfen und berichten.

   • Entdecken Sie Befehle aus dem Wrapper des Repositorys, Modulen, Plugins, Quellsets und der CI-Konfiguration. Lesen Sie references/java-testing-tooling.md für Build- und Fehlerbehandlungsregeln.
   • Führen Sie zuerst den engsten relevanten Testbefehl aus, dann die breitere Suite, wenn der Schadensradius dies rechtfertigt.
   • Wenn ein höherstufiger Test einen Fehler aufdeckt, den kein niedrigerer Test erfasst, fügen Sie einen niedrigeren Regressionstest hinzu.
   • Entfernen oder vermeiden Sie doppelte hochstufige Prüfungen, wenn niedrigere Tests die Bedingungen bereits abdecken und der hochstufige Test kein einzigartiges Vertrauen hinzufügt.
   • Berichten Sie über hinzugefügte oder überprüfte Tests, abgedeckte Verhaltensweisen, Befehle und Ergebnisse, Fehler oder nicht verfügbare Prüfungen und verbleibende Risiken. Unterscheiden Sie neue Fehler von bestätigten bereits vorhandenen oder umgebungsbedingten Fehlern.

Referenzen

Lesen Sie references/test-pyramid.md, wenn Sie Testumfang, CI-Platzierung, Duplizierung oder entscheiden, wie viel End-to-End-Testing hinzugefügt werden soll.

Lesen Sie references/java-testing-tooling.md, wenn Sie Java-Testwerkzeuge, Abhängigkeiten, Annotationen, Mocking-Stil, Spring Boot Test-Form, Testcontainers-Muster, API-Tests, Vertragstests, Build-Befehle oder Fehlerklassifizierung wählen.