Kurzfassung
Red/Green/Refactor beschreibt den dreistufigen Rhythmus von TDD: Ein fehlschlagender Test (Red) definiert das gewünschte Verhalten, minimaler Code lässt ihn bestehen (Green) und dann wird der Code aufgeräumt (Refactor), ohne die Tests zu brechen.
Was ist Red/Green/Refactor?
Der Zyklus beginnt mit Red: Schreibe einen Test für eine kleine Funktionalität, die noch nicht existiert. Der Test schlägt fehl, weil der Code nicht implementiert ist – die meisten Testing-Frameworks zeigen dies als rot in ihrer Ausgabe an.
Green: Schreibe den einfachsten Produktionscode, der den fehlschlagenden Test besteht. Das Ziel ist Korrektheit, nicht Eleganz. Sobald der Test besteht – die Ausgabe wird grün – ist der erste Teil des Zyklus abgeschlossen.
Refactor: Jetzt wird der Code verbessert. Duplikationen entfernen, Namen klären, Logik vereinfachen. Die Test-Suite dient als Sicherheitsnetz – wenn ein Test beim Refactoring rot wird, erkennt der Entwickler sofort, dass etwas gebrochen ist. Nach dem Refactoring sollten alle Tests wieder grün sein.
Dieser Zyklus, der typischerweise zwei bis zehn Minuten dauert, hält die Entwicklung inkrementell, Fehler klein und das Design kontinuierlich verbessernd.
Warum ist Red/Green/Refactor relevant?
- Inkrementeller Fortschritt: Kleine Zyklen reduzieren das Risiko großer, schwer zu debuggender Fehler
- Kontinuierliche Design-Verbesserung: Der Refactor-Schritt verhindert das Ansammeln technischer Schulden
- Sofortiges Feedback: Ein fehlschlagender Test nach dem Refactoring zeigt genau die Änderung, die das Verhalten gebrochen hat