Testgetriebene Entwicklung

Was macht Testgetriebene Entwicklung?

TDD ist der rot → grün Loop. Dieser Skill ist die Referenz, die diesen Loop dazu bringt, Tests zu erzeugen, die es wert sind, behalten zu werden: was ein guter Test ist, wo Tests hingehören, die Anti-Patterns und die Regeln des Loops. Jeder Abschnitt gilt in jedem Zyklus: konsultiere sie vor und während des Loops, nicht danach.

Wenn du die Codebasis erkundest, lies GLOSSARY.md (falls vorhanden), damit Testnamen und Schnittstellen-Vokabular mit der Domain-Sprache des Projekts übereinstimmen, und respektiere ADRs in dem Bereich, den du bearbeitest.

Was ein guter Test ist

Tests überprüfen Verhalten durch öffentliche Schnittstellen, nicht durch Implementierungsdetails. Code kann sich vollständig ändern; Tests sollten das nicht. Ein guter Test liest sich wie eine Spezifikation: „Benutzer kann mit gültigem Warenkorb auschecken“ sagt dir genau, welche Fähigkeit existiert, und überlebt Refaktorisierungen, weil er sich nicht um die interne Struktur schert.

Siehe tests.md für Beispiele und mocking.md für Richtlinien zum Mocken.

Seams: Wo Tests hingehören

Ein Seam ist die öffentliche Grenze, an der du testest: die Schnittstelle, an der du Verhalten beobachtest, ohne in das Innere zu greifen. Tests leben an Seams, niemals gegen Interna.

Teste nur an vorab vereinbarten Seams. Bevor du einen Test schreibst, schreibe die zu testenden Seams auf und bestätige sie mit dem Benutzer. Kein Test wird an einem unbestätigten Seam geschrieben. Du kannst nicht alles testen, daher ist die vorherige Abstimmung der Seams der Weg, wie Testaufwand auf die kritischen Pfade und komplexen Logiken gelenkt wird, anstatt auf jeden Randfall.

Frage: „Was ist die öffentliche Schnittstelle, und welche Seams sollten wir testen?“ Gib jedem vorgeschlagenen Seam eine einzeilige Notiz darüber, was er abdeckt und was er verfehlt.

Wenn die Form dieser Schnittstelle selbst fraglich ist (wie tief das Modul ist, wo der Seam hingehört, was die Schnittstelle exponieren sollte), rufe das Skill-Tool mit „codebase-design“ für das Vokabular auf. Es ist die gemeinsame Quelle der Begriffe Modul, Schnittstelle, Tiefe, Seam, Adapter, Hebelwirkung und Lokalität und eine Referenz zum Nachschlagen, keine Sitzung zum Ausführen.

Anti-Patterns

• Implementationsgekoppelt: Mockt interne Kollaborateure, testet private Methoden oder verifiziert über einen Seitenkanal (Abfrage der Datenbank anstelle der Schnittstelle). Das Anzeichen: Der Test bricht bei Refaktorisierung, obwohl sich das Verhalten nicht geändert hat.
• Tautologisch: Die Assertion berechnet den erwarteten Wert so nach, wie der Code es tut (expect(add(a, b)).toBe(a + b), ein Snapshot, der auf dieselbe Weise manuell abgeleitet wurde, eine Konstante, die mit sich selbst gleichgesetzt wird), also besteht er konstruktionsbedingt und kann niemals mit dem Code in Konflikt geraten. Erwartete Werte müssen aus einer unabhängigen Wahrheitsquelle stammen: einem bekannten korrekten Literal, einem durchgerechneten Beispiel, der Spezifikation.
• Horizontales Schichten: Zuerst alle Tests schreiben, dann die gesamte Implementierung. Massentests überprüfen imaginiertes Verhalten: Du testest die Form der Dinge anstelle von benutzersichtigem Verhalten, die Tests werden unempfindlich gegenüber echten Änderungen, und du verpflichtest dich auf eine Teststruktur, bevor du die Implementierung verstehst. Arbeite stattdessen in vertikalen Slices: ein Test → eine Implementierung → wiederholen, jeder Test ein Tracer Bullet, der auf das reagiert, was der letzte Zyklus dich gelehrt hat.

Regeln des Loops

• Rot vor Grün. Schreibe zuerst den fehlschlagenden Test, dann nur genug Code, um ihn zu bestehen. Antizipiere keine zukünftigen Tests oder füge spekulative Funktionen hinzu.
• Ein Slice nach dem anderen. Ein Seam, ein Test, eine minimale Implementierung pro Zyklus.
• Refaktorisierung gehört nicht zum Loop. Sie gehört zur Überprüfungsphase (siehe den code-review Skill), nicht zum rot → grün Implementierungszyklus.