Red/Green TDD ist Kent Becks klassischer Zyklus der testgetriebenen Entwicklung aus „Test-Driven Development: By Example“ (2002): zuerst ein fehlschlagender Test (Red), dann das Minimum an Code, das ihn bestehen lässt (Green), danach Refactoring mit den Tests als Sicherheitsnetz. Die Zyklen sind bewusst klein, es schlägt immer nur ein Test fehl, und Verallgemeinerung geschieht im Refactoring. Simon Willison machte den Zyklus als Anweisung für LLM-Coding-Agents bekannt.

Red/Green TDD

Details
Auch bekannt als

Red-Green-Refactor, Klassischer TDD-Zyklus, Test-First-Entwicklung

Kernkonzepte:

Red-Phase

Schreibe zuerst einen fehlschlagenden Test, bevor irgendwelcher Produktionscode existiert. Der Test muss tatsächlich laufen und aus dem richtigen Grund scheitern — Kompilierfehler zählen nicht als rot.

Green-Phase

Schreibe das Minimum an Produktionscode, das den fehlgeschlagenen Test grün macht. Widerstehe dem Drang, Funktionalität hinzuzufügen, die der Test nicht verlangt.

Refactor-Phase

Mit grünen Tests verbessere das Design — umbenennen, extrahieren, Duplikate entfernen — im Vertrauen darauf, dass die Testsuite Regressionen fängt.

Kleine Schritte

Jeder Zyklus ist bewusst klein (Sekunden bis Minuten), nicht Stunden. Große Sprünge zerstören die Feedback-Schleife.

Scheitern beobachten

Zu verifizieren, dass der Test tatsächlich vor der Implementierung fehlschlägt, fängt tautologische Tests und Tippfehler im Test selbst.

Testnamen beschreiben Verhalten

Nicht Methodennamen. "Gibt leere Liste zurück, wenn keine Benutzer existieren" sagt, was der Code tut; "test getUsers" nicht.

Minimum zum Bestehen

"Fake it" (return 42), hardcoden, kopieren — was auch immer den Test am schnellsten grün macht. Verallgemeinerung passiert in der Refactor-Phase durch Triangulation.

Ein Test nach dem anderen

Zu jedem Zeitpunkt nur ein fehlschlagender Test in der Suite. Niemals einen zweiten fehlschlagenden Test hinzufügen, bevor der erste grün ist.

Schlüsselvertreter

Kent Beck ("Test-Driven Development: By Example", 2002); für LLM-Coding-Agents popularisiert durch Simon Willison

Wann zu verwenden:

  • Instruktion von LLM-Coding-Agents, die standardmäßig Features zuerst implementieren und Tests hinterher schreiben

  • Neuer Produktionscode, bei dem Anforderungen als konkrete Beispiele ausgedrückt werden können

  • Bugfixes — schreibe einen fehlschlagenden Test, der den Bug reproduziert, dann behebe ihn

  • Refactoring von Legacy-Code ohne Testabdeckung (beginne mit Charakterisierungstests)

  • Vermittlung disziplinierter inkrementeller Entwicklung

Verwandte Anker:

Kritik:

  • David Heinemeier Hansson, "TDD is dead. Long live testing." (2014) — Test-First als Dogma führe zu "test-induced design damage"; die anschließende Gesprächsreihe "Is TDD Dead?" mit Kent Beck und Martin Fowler kartiert die gesamte Debatte

  • James O. Coplien, "Why Most Unit Testing is Waste" (2013) — die meisten Low-Level-Unit-Tests liefern wenig Absicherung im Verhältnis zu ihren Wartungskosten

  • Die empirische Lage ist gemischt: Replikationsstudien (z. B. Fucci et al., "A Dissection of the Test-Driven Development Process", IEEE TSE 2017) legen nahe, dass die beobachteten Vorteile aus kleinen iterativen Schritten stammen, nicht aus dem Schreiben des Tests zuerst