TDD: Red-Green-Refactor

Bisher haben wir Tests betrachtet, die nach dem Code geschrieben werden – klassisch. TDD (Test-Driven Development) dreht das radikal um: der Test wird zuerst geschrieben, dann der Code. Klingt rückwärts, ist aber eine der einflussreichsten Praktiken der modernen Software-Entwicklung. Erfunden von Kent Beck im Rahmen von Extreme Programming, heute Standard in vielen Teams.

Der zentrale Rhythmus heißt Red-Green-Refactor: erst einen Test schreiben (rot – schlägt fehl), dann den minimalsten Code schreiben, um den Test zu erfüllen (grün), und schließlich aufräumen (refactor), ohne den grünen Zustand zu verlieren. Diese Lektion zeigt den Zyklus Schritt für Schritt anhand eines konkreten Beispiels.

1) Warum überhaupt umdrehen?

Beim klassischen „Code-First"-Ansatz schreibt man Code, der eine Vorstellung der Anforderung umsetzt – und prüft hinterher, ob das stimmt. Probleme:

Tests werden zum Code passend geschrieben, nicht zur Anforderung. Sie bestätigen, was der Code tut, nicht was er tun soll.
Tests entstehen oft nie – weil „der Code ja funktioniert" und Zeitdruck herrscht.
Es ist nicht klar, wann man fertig ist.

TDD löst diese Probleme: der Test ist die ausführbare Spezifikation. Solange der Test rot ist, fehlt etwas. Sobald er grün ist, ist die Anforderung erfüllt. Das ist die Stärke des Ansatzes.

2) Der Red-Green-Refactor-Zyklus

Der TDD-Rhythmus

Der Zyklus läuft sehr schnell: ein Durchgang dauert oft nur Minuten. Pro Zyklus wird eine winzige Anforderung umgesetzt. Über einen Arbeitstag durchläufst du den Zyklus 30-50 Mal. So baut sich der Code Stück für Stück auf, getrieben von Tests – daher der Name Test-Driven Development.

3) Konkretes Beispiel: FizzBuzz von Hand

Klassiker zum Üben: FizzBuzz. Eine Funktion, die für eine Zahl entweder die Zahl selbst zurückgibt, oder "Fizz" (durch 3 teilbar), "Buzz" (durch 5), oder "FizzBuzz" (durch beide). Lass uns das TDD-mäßig aufbauen – klick durch die Phasen:

FizzBuzz mit TDD – Phase für Phase

Zyklus 1: RED – Erster Test

test("Zahl 1 gibt '1' zurück", () => { expect(fizzBuzz(1)).toBe("1"); }); // Ergebnis: ✗ ReferenceError: fizzBuzz is not defined

Wir starten mit dem einfachsten möglichen Test. Die Funktion existiert noch gar nicht – natürlich schlägt der Test fehl. Das ist OK, das ist genau das Ziel der Red-Phase: ein Test, der eindeutig fehlschlägt.

Beobachte die Strategie: kleinste mögliche Schritte. Wir schreiben nicht den ganzen FizzBuzz auf einmal. Wir bauen Stück für Stück: erst eine simple Zahl, dann „Fizz", dann „Buzz", dann „FizzBuzz". Mit jedem Zyklus wird die Funktion einen Tick smarter. Das fühlt sich umständlich an, ist aber genau richtig: jeder Test sichert ab, kein Schritt führt zu Regressionen.

4) Die drei Phasen im Detail

RED – den Test schreiben: formuliere als Test, was du als Nächstes erreichen willst. Der Test muss fehlschlagen – das beweist, dass er was misst. Ein grüner Test als Start wäre verdächtig (testet er überhaupt was Sinnvolles?).

GREEN – Test grün bekommen: schreibe den minimalsten Code, der den Test bestehen lässt. Auch wenn das Code ist, der dir technisch wehtut („return 1;" ist gerade richtig, weil der Test nur 1 testet). Die Versuchung, mehr zu schreiben, ist groß – aber widerstehen. Hinter dem nächsten Test versteckt sich die Forderung nach mehr.

REFACTOR – aufräumen: die Funktion vergrößern, Duplikate entfernen, Magic Numbers in Konstanten, bessere Namen. Alles, was den Code verbessert, ohne sein Verhalten zu ändern. Tests laufen lassen – wenn alle grün bleiben, ist das Refactoring sicher.

5) Die wichtigste TDD-Regel: kleine Schritte

Anfänger machen oft den Fehler, große Sprünge zu machen. Baby Steps sind das Geheimnis von TDD. Wenn du nicht weißt, wie du den Test grün bekommst, schreibst du nicht den richtigen Test. Mach den Test einfacher.

Konkret: ein Zyklus sollte Sekunden bis Minuten dauern. Wenn du 30 Minuten an einem grünen Test arbeitest, hast du den falschen Test geschrieben. Lösch ihn, mach einen kleineren Schritt.

6) Vorteile von TDD

Was TDD wirklich bringt

✓ Bessere Architektur

Code, der mit Tests geschrieben wird, ist automatisch testbar. Das zwingt zu sauberen Schnittstellen, Dependency Injection, kleinen Methoden.

✓ 100 % Coverage

Per Definition: jede Codezeile entstand aus einem Test, also gibt es für jede einen Test. Vgl. L4.

✓ Selbstdokumentation

Tests beschreiben, was der Code tun soll – lesbarer als jede Doku. Wer den Code verstehen will, liest die Tests zuerst.

✓ Refactoring-Sicherheit

Die grünen Tests sind dein Netz. Du kannst mutig umbauen – wenn Tests danach noch grün sind, ist alles gut.

✓ Fokus auf das Wesentliche

Der nächste Test bestimmt, was du tust. Kein „könnte später mal nützlich sein"-Code. YAGNI (You Aren't Gonna Need It).

✓ Schnellere Feedback-Loop

Du weißt in Sekunden, ob deine letzte Änderung gut war – keine 10-Minuten-Debug-Sessions.

7) Nachteile und Kritik

TDD ist nicht universell beliebt. Wichtige Kritikpunkte:

Steile Lernkurve. Bis du den Rhythmus drin hast, dauert es Wochen.
Mehraufwand am Anfang. Tests schreiben braucht Zeit. Erst auf lange Sicht zahlt sich das aus (Refactoring + Wartung).
Nicht für jeden Code-Typ. Explorative Datenanalyse, Prototypen, GUI-Layout – hier ist TDD weniger geeignet.
Verleitet zu Über-Mocking. Wenn du nur Unit-Tests durchs ganze System ziehst, mockst du am Ende alles – ohne dass das System wirklich funktioniert. Siehe L7.
Tests sind Code. Sie wollen auch gewartet werden. Schlechte Tests sind schlimmer als keine.

In der Praxis macht kaum jemand 100 % TDD. Viele Teams nutzen TDD für kritische Logik (Berechnungen, Validierungen), schreiben sonst Tests klassisch nach.

8) TDD vs. Test-After-Development

Die Standard-Methode außerhalb TDD: erst Code, dann Tests. Auch das ist legitim, hat aber andere Eigenschaften:

Code wird oft schwerer testbar (enge Kopplungen, statische Methoden).
Tests werden weggelassen, wenn die Zeit knapp wird.
Tests prüfen, was der Code tut, nicht was er tun soll.

Mittelweg: Test-Last – Code schreiben, sofort danach Tests. Nicht so streng wie TDD, aber besser als „Tests irgendwann".

9) BDD – Verwandter Ansatz

Behavior-Driven Development (BDD) ist eine Weiterentwicklung von TDD. Tests werden in natürlicher Sprache formuliert – das Verhalten aus User-Sicht. Bekannt durch Tools wie Cucumber (Java/Ruby) oder SpecFlow (.NET) mit Gherkin-Syntax:

Feature: FizzBuzz
  Scenario: Zahl 3 gibt Fizz zurück
    Given die Funktion fizzBuzz
    When ich fizzBuzz(3) aufrufe
    Then bekomme ich "Fizz" zurück

BDD ist gut für die Kommunikation mit nicht-technischen Stakeholdern. Auch hier gilt das Red-Green-Refactor-Prinzip.

10) TDD in der IHK-Klausur

TDD ist Teil des Rahmenplans (B2c). Was in Klausuren typisch abgefragt wird:

Die 3 Phasen Red-Green-Refactor erklären können.
Reihenfolge: Test vor Code, nicht umgekehrt.
Eine Iteration durchspielen: zu einer Anforderung den ersten Test, den Minimal-Code, das Refactoring skizzieren.
Vorteile nennen (Coverage, Refactoring-Sicherheit, Doku-Charakter).
Abgrenzung zu „Test-Last"-Ansätzen.

Zusammenfassung

TDD dreht die Reihenfolge um: Test zuerst, dann Code. Rhythmus Red-Green-Refactor: kleinen Test schreiben (rot), Minimal-Code schreiben (grün), aufräumen ohne grün zu verlieren. Baby Steps in Sekunden bis Minuten. Vorteile: testbare Architektur, 100% Coverage, Tests als Doku, sicheres Refactoring. Nachteile: Lernkurve, ungeeignet für Prototypen, Über-Mocking-Gefahr. BDD erweitert TDD mit natürlicher Sprache (Gherkin). Nächste Lektion: Unit-Tests schreiben.