Testgetriebene Entwicklung
Ausgabesprache
Standardmäßig wird mit dem Benutzer in vereinfachtem Chinesisch kommuniziert, und Teststrategien, Testspezifikationen und Implementierungszusammenfassungen werden in vereinfachtem Chinesisch verfasst. Falls der Benutzer explizit eine andere Sprache angibt oder die vorhandene Dokumentation eine andere Sprache vorsieht, wird dieser Vorgabe gefolgt; Code, Befehle, Produktnamen und wörtliche Zitate, die im Original erhalten bleiben müssen, werden nicht zwangsweise übersetzt.
Philosophie
Grundprinzip: Tests sollten das Verhalten über öffentliche Schnittstellen verifizieren, nicht über Implementierungsdetails. Code kann sich vollständig ändern; Tests sollten das nicht.
Gute Tests sind integrationsorientiert: Sie durchlaufen echte Codepfade über öffentliche APIs. Sie beschreiben was das System tut, nicht wie es es tut. Ein guter Test liest sich wie eine Spezifikation – „Benutzer kann mit gültigem Warenkorb zur Kasse gehen“ sagt Ihnen genau, welche Fähigkeit existiert. Diese Tests überleben Refaktorisierungen, weil sie sich nicht um die interne Struktur kümmern.
Schlechte Tests sind an die Implementierung gekoppelt. Sie mocken interne Kollaborateure, testen private Methoden oder verifizieren über externe Wege (z.B. eine Datenbank direkt abfragen anstatt die Schnittstelle zu nutzen). Das Warnsignal: Ihr Test bricht bei einer Refaktorisierung, obwohl sich das Verhalten nicht geändert hat. Wenn Sie eine interne Funktion umbenennen und Tests fehlschlagen, haben diese Tests die Implementierung getestet, nicht das Verhalten.
Siehe tests.md für Beispiele und mocking.md für Mocking-Richtlinien.
Anti-Pattern: Horizontale Schnitte
Schreiben Sie NICHT alle Tests zuerst, dann die gesamte Implementierung. Dies ist ein „horizontaler Schnitt“ – ROT als „alle Tests schreiben“ und GRÜN als „allen Code schreiben“ zu behandeln.
Dies produziert miese Tests:
- Tests, die in großen Mengen geschrieben werden, testen vorgestelltes Verhalten, nicht tatsächliches Verhalten
- Sie testen am Ende die Form der Dinge (Datenstrukturen, Funktionssignaturen) anstatt benutzerseitiges Verhalten
- Tests werden unempfindlich gegenüber echten Änderungen – sie bestehen, wenn Verhalten bricht, und schlagen fehl, wenn Verhalten in Ordnung ist
- Sie überholen Ihre Scheinwerfer, indem Sie sich auf eine Teststruktur festlegen, bevor Sie die Implementierung verstehen
Richtiger Ansatz: Vertikale Schnitte mit Tracer Bullets. Ein Test → eine Implementierung → wiederholen. Jeder Test reagiert auf das, was Sie aus dem vorherigen Zyklus gelernt haben. Weil Sie gerade den Code geschrieben haben, wissen Sie genau, welches Verhalten wichtig ist und wie Sie es verifizieren können.
FALSCH (horizontal):
ROT: test1, test2, test3, test4, test5
GRÜN: impl1, impl2, impl3, impl4, impl5
RICHTIG (vertikal):
ROT→GRÜN: test1→impl1
ROT→GRÜN: test2→impl2
ROT→GRÜN: test3→impl3
...
Arbeitsablauf
1. Planung
Beim Erkunden der Codebasis lesen Sie CONTEXT.md (falls vorhanden), sodass Testnamen und Schnittstellenvokabular mit der Domänensprache des Projekts übereinstimmen, und respektieren Sie ADRs in dem Bereich, den Sie bearbeiten.
Bevor Sie Code schreiben:
- Bestätigen Sie mit dem Benutzer, welche Schnittstellenänderungen nötig sind
- Bestätigen Sie mit dem Benutzer, welche Verhaltensweisen getestet werden sollen (priorisieren)
- Identifizieren Sie Möglichkeiten für tiefe Module mithilfe von Codebasis-Designprinzipien, wenn Schnittstellengrenzen unklar sind. Rufen Sie nicht automatisch eine andere Skill auf, es sei denn, der Benutzer fragt explizit danach.
- Listen Sie die zu testenden Verhaltensweisen auf (nicht Implementierungsschritte)
- Holen Sie die Zustimmung des Benutzers zum Plan ein
Fragen Sie: „Wie sollte die öffentliche Schnittstelle aussehen? Welche Verhaltensweisen sind am wichtigsten zu testen?“
Sie können nicht alles testen. Stimmen Sie mit dem Benutzer genau ab, welche Verhaltensweisen am wichtigsten sind. Konzentrieren Sie die Testarbeit auf kritische Pfade und komplexe Logik, nicht auf jeden möglichen Randfall.
2. Tracer Bullet
Schreiben Sie EINEN Test, der EINE Sache über das System bestätigt:
ROT: Test für erstes Verhalten schreiben → Test schlägt fehl
GRÜN: Minimalen Code schreiben, um zu bestehen → Test besteht
Dies ist Ihre Tracer Bullet – beweist, dass der Pfad durchgängig funktioniert.
3. Inkrementelle Schleife
Für jedes verbleibende Verhalten:
ROT: Nächsten Test schreiben → schlägt fehl
GRÜN: Minimalen Code schreiben, um zu bestehen → besteht
Regeln:
- Ein Test nach dem anderen
- Nur genug Code, um den aktuellen Test zu bestehen
- Zukünftige Tests nicht vorwegnehmen
- Tests auf beobachtbares Verhalten konzentrieren
4. Refaktorisierung
Nachdem alle Tests bestanden sind, suchen Sie nach Refaktorisierungs-Kandidaten:
- Duplikation extrahieren
- Module vertiefen (Komplexität hinter einfache Schnittstellen verschieben)
- SOLID-Prinzipien anwenden, wo sie natürlich sind
- Überlegen, was neuer Code über bestehenden Code verrät
- Tests nach jedem Refaktorisierungsschritt ausführen
Nie während ROT refaktorisieren. Erreichen Sie zuerst GRÜN.
Checkliste pro Zyklus
[ ] Test beschreibt Verhalten, nicht Implementierung
[ ] Test verwendet nur öffentliche Schnittstelle
[ ] Test würde eine interne Refaktorisierung überleben
[ ] Code ist minimal für diesen Test
[ ] Keine spekulativen Funktionen hinzugefügt