Test Standards
Regelset zur Beschränkung KI-generierter Testcodes. Drei Inhalte:
- unit-test-standards.md: Unit-Tests — AAA-Struktur / Mock-Regeln / Assertionsstil / Testisolierung
- contract-test-standards.md: Vertragstests — Übersetzung von Abnahmeszenarien / Drei-Zustands-Abdeckung / Erst Rot, dann Grün
- test-data-standards.md: Testdaten — Datenfabrik / Testcontainers / Isolation
Ladematrix
| Aufgabentyp | Pflichtlektüre |
|---|---|
| Unit-Tests schreiben | standards/unit-test-standards.md |
| Schnittstellen-Vertragstests schreiben (angebunden an ai-dev-workflow 4.2) | standards/contract-test-standards.md + standards/unit-test-standards.md |
| Testdaten vorbereiten / Datenbank-Integrationstests | standards/test-data-standards.md |
| Testcode reviewen | Alle (nach entsprechendem Typ) |
Kurzübersicht Kernregeln
- Tests sind Akzeptanzkriterien: Kein Ändern von Behauptungen / Löschen von Tests / @Disabled (Code darf sich nicht den Tests anpassen)
- Ein Test, ein Verhalten; AAA-Struktur; Assertions mit AssertJ fließend
- Testmethodennamen auf Englisch in camelCase (z.B.
createOrderShouldReturn400WhenUserNotExist), keine chinesischen/pinyinischen Methodennamen; Anwendungsfälle auf Chinesisch im Javadoc - Alle Abhängigkeiten mocken, Implementierungsdetails nicht testen; kein
Thread.sleep - Vertragstests decken drei Zustände ab (gültig / ungültig / Grenzen), erst rot, dann grün
- Testdaten fabrikmäßig; komplexes SQL mit Testcontainers auf echter Datenbank
- Testisolierung: Keine Abhängigkeit von der Ausführungsreihenfolge, keine gemeinsamen veränderlichen Zustände
Beziehung zu anderen Skills
- ai-dev-workflow: 4.2
/contract-testsVertragstest-Prozess verweist auf contract-test-standards dieses Skills (Prozess im Prozess-Skill, Codenormen in diesem Skill) - java-code-standards: Java-Codenormen verweisen auf diesen Skill (wird beim Schreiben von Tests geladen)
- database-standards / comment-standards: Keine direkte Referenz
Nutzungsanforderungen
Vor dem Generieren von Testcode die Regeln gemäß „Aufgabentyp → Ladematrix“ lesen; nach der Generierung die Checkliste der entsprechenden Spezifikation Punkt für Punkt abarbeiten. Vertragstests: erst rot, dann grün – die Rot-Ursache muss „Implementierung existiert nicht“ sein, nicht „Test ist falsch geschrieben“.