Testgetriebene Entwicklung (TDD)
Schreibe zuerst den fehlschlagenden Test. Sieh zu, wie er fehlschlägt. Schreibe minimalen Code, um ihn zu bestehen. Refaktoriere. Ein Test, der sofort besteht, beweist nichts – du hast nie gesehen, dass er einen Fehler gefunden hat.
Eisernes Gesetz: Kein Produktionscode ohne einen zuvor fehlschlagenden Test. Wenn du Code vor dem Test geschrieben hast, lösche ihn und beginne von vorn. „Als Referenz behalten“ ist getarntes Test-nach-dem-Code – löschen bedeutet löschen.
Wann anwenden
- Implementierung einer neuen Funktion oder eines neuen Verhaltens
- Behebung eines Fehlers (reproduziere ihn zuerst mit einem Test – das „Beweis-es“-Muster)
- Refactoring oder Änderung bestehenden Verhaltens
- Auslöser: „tdd“, „test-driven“, „red green refactor“, „测试驱动开发“, „红绿重构“, „测试驱动“
Nicht für: Generieren von Tests für bereits geschriebenen Code (verwende test-generation); Wegwerfprototypen oder reine Konfiguration (einfach direkt umsetzen).
Ausnahmen (mit dem Benutzer abklären): Wegwerfprototypen, generierter Code, reine Konfigurationsänderungen ohne Verhaltensauswirkungen.
Schritte
0. Erkenne zuerst den Stack
Der Zyklus ist universell; die Befehle sind es nicht. Finde vor dem ersten Test heraus, wie dieses Repository testet: Lies package.json / pyproject.toml / Cargo.toml / pom.xml / go.mod, suche nach ./gradlew, Makefile, CI-Workflows und vorhandenen Testdateinamen. Gehe niemals von npm test aus – verwende für jede ROT-, GRÜN- und abschließende Verifikation den eigenen Befehl des Repos.
1. ROT – schreibe einen fehlschlagenden Test
Ein Verhalten, ein Test, ein vertikaler Schnitt (Tracer-Geschoss, das auf das reagiert, was dir der letzte Zyklus gelehrt hat). Schreibe den Test, den du dir wünschst – er beschreibt die gewünschte API, nicht die Implementierung. Benenne ihn als Spezifikation („lehnt leere E-Mail ab“, nicht „test1“).
Vereinbare den Naht (öffentliches Interface, das getestet wird), bevor du schreibst. Kein Test an einem nicht bestätigten Naht – das frühzeitige Vereinbaren von Nähten konzentriert die Testarbeit auf kritische Pfade statt auf jeden Randfall. Verwende echten Code statt Mocks; falls du eine Abhängigkeit doubeln musst, verwende den einfachsten Double, der funktioniert (Real > Fake > Stub > Mock – siehe references/test-strategy.md). Mocks isolieren Grenzen, nicht das zu testende Objekt.
2. Verifiziere ROT – sieh zu, wie er fehlschlägt
Führe den fokussierten Testbefehl aus. Bestätige:
- Er schlägt fehl (kein Fehler – Fehler bedeuten, die Einrichtung korrigieren und erneut ausführen)
- Er schlägt aus dem richtigen Grund fehl (Funktion fehlt, kein Tippfehler)
- Ein Test, der sofort besteht, bedeutet, dass du vorhandenes Verhalten testest – korrigiere den Test
3. GRÜN – schreibe minimalen Code
Der einfachste Code, der den Test besteht. Keine spekulativen Funktionen, keine „Flexibilität“, kein Refactoring von angrenzendem Code. YAGNI. Füge keine test-only-Methoden (destroy(), reset()) zu Produktionsklassen hinzu – platziere die Bereinigung in Test-Hilfsprogrammen.
4. Verifiziere GRÜN – sieh zu, wie er besteht
Führe den fokussierten Testbefehl aus, dann die gesamte Suite. Bestätige:
- Der neue Test besteht
- Keine anderen Tests sind kaputtgegangen (falls doch, repariere sie sofort – überspringe nichts)
- Die Ausgabe ist makellos (keine Warnungen, keine übersprungenen Tests)
5. REFACTOR – aufräumen
Nur während Grün: Extrahiere Hilfsfunktionen, verbessere Namen, entferne Duplikate. Führe Tests nach jedem Refactoring-Schritt aus. Füge kein Verhalten hinzu. Refactoring gehört zur Überprüfungsphase, nicht zum Rot→Grün-Implementierungszyklus.
6. Committen
Commite Test und Implementierung zusammen als einen vertikalen Schnitt. Beginne dann mit dem nächsten fehlschlagenden Test.
Fehlerbehebungen – das „Beweis-es“-Muster
Beginne nicht mit dem Beheben. Schreibe einen Test, der den Fehler reproduziert (ROT bestätigt, dass er existiert), dann behebe ihn (GRÜN beweist, dass die Behebung funktioniert). Der Test bleibt als Regression Guard. Behebe niemals einen Fehler ohne einen Reproduktionstest.
Verifizieren
- Jedes neue Verhalten hat einen Test, der zuerst fehlschlug
- Die gesamte Suite besteht mit dem eigenen Testbefehl des Repos
- Fehlerbehebungen enthalten einen Reproduktionstest, der vor der Behebung fehlschlug
- Testnamen beschreiben das Verhalten, nicht die Implementierung
- Keine Tests übersprungen oder deaktiviert; keine test-only-Methoden im Produktionscode
Referenzen
- ${CLAUDE_PLUGIN_ROOT}/references/engineering-principles.md – Disziplin, die jede Fähigkeit teilt
- references/test-strategy.md – Testpyramide, Test-Double-Hierarchie (Real > Fake > Stub > Mock), DAMP über DRY
- references/testing-anti-patterns.md – Mock-Missbrauch, test-only-Methoden, partielle Mocks, Torfunktionen
- references/mocking.md – Wann mocken, Entwurf für Mockbarkeit
- references/good-tests.md – Beispiele für gute vs. schlechte Tests, tautologische Tests