Test-Driven Development Erst der Test, dann der Code

Normalerweise schreibst du erst den Code und dann den Test. TDD dreht das um: Du schreibst zuerst einen Test, der fehlschlägt — dann gerade genug Code, damit er besteht — und räumst anschließend auf. Dieser Dreierschritt heißt Red-Green-Refactor und dauert oft nur wenige Minuten. Klingt rückwärts? Ist aber der schnellste Weg zu Code, dem du vertrauen kannst.

TDD auf einen Blick

Was?
Entwicklungsmethode: Erst Test schreiben, dann Code implementieren
Zyklus
Red → Green → Refactor (alle 2-10 Minuten)
Effekt
40-80 % weniger Fehler in Produktion (laut IBM/Microsoft-Studien)
Voraussetzung
Unit-Test-Framework (JUnit, pytest, Jest etc.)

Wie funktioniert der Red-Green-Refactor-Zyklus?

TDD besteht aus drei Schritten, die du in rascher Folge wiederholst — wie ein Herzschlag für deinen Code:

Red Test schreiben (schlägt fehl) Green Code schreiben (Test besteht) Refactor Code aufräumen
Der TDD-Zyklus: Red → Green → Refactor
  1. Red: Schreibe einen Test für eine Funktion, die noch nicht existiert. Lass ihn laufen — er muss fehlschlagen. Wenn er sofort grün ist, testet er nichts Sinnvolles.
  2. Green: Schreibe den einfachsten Code, der den Test bestehen lässt. Nicht mehr. Keine Optimierung, keine Abstraktion — nur gerade genug, damit es funktioniert.
  3. Refactor: Jetzt räumst du auf. Duplikate entfernen, Namen verbessern, Struktur klären. Die Tests geben dir dabei das Sicherheitsnetz: Solange sie grün bleiben, hast du nichts kaputt gemacht.

Ein Durchlauf dauert typischerweise 2 bis 10 Minuten. In einer Stunde durchläufst du den Zyklus also zehn- bis dreißigmal. Das Ergebnis: Code, der von Anfang an getestet ist — nicht nachträglich.

Warum den Test vor dem Code schreiben?

Tests nach dem Coden sind wie eine Versicherung, die du nach dem Unfall abschließt. Sie werden oft vergessen, unter Zeitdruck gestrichen oder so geschrieben, dass sie nur bestätigen, was der Code ohnehin tut.

TDD dreht die Reihenfolge um — und ändert damit die Denkweise:

  • Du denkst über das Verhalten nach, nicht über die Implementierung. „Was soll diese Funktion zurückgeben?" statt „Wie baue ich diese Funktion?"
  • Du schreibst nur Code, den du wirklich brauchst. Kein Over-Engineering, keine spekulativen Features.
  • Du bekommst sofort Feedback. Funktioniert es oder nicht? Die Antwort kommt in Sekunden.

Wie sieht TDD in der Praxis aus?

Ein konkretes Beispiel: Du sollst eine Funktion bauen, die E-Mail-Adressen validiert.

  1. Red: Du schreibst einen Test: „test@example.com soll gültig sein". Der Test schlägt fehl, weil die Funktion noch nicht existiert.
  2. Green: Du schreibst die einfachste Validierung. Der Test wird grün.
  3. Red: Neuer Test: „test@ soll ungültig sein". Fehlschlag.
  4. Green: Du erweiterst die Validierung. Grün.
  5. Refactor: Du fasst doppelten Code zusammen und verbesserst die Lesbarkeit.

Nach 20 Minuten hast du eine robuste Validierung mit zehn Tests — und jeder Grenzfall ist abgedeckt. Ohne TDD hättest du vermutlich drei der Grenzfälle vergessen.

Wo stößt TDD an seine Grenzen?

TDD ist mächtig, aber kein Allheilmittel:

  • UI-Code: Visuelle Elemente lassen sich schwer automatisiert testen. Hier helfen ergänzende Ansätze wie Snapshot-Tests.
  • Prototypen: Wenn du noch nicht weißt, WAS du bauen willst, ist TDD zu starr. Erst explorieren, dann testen.
  • Legacy-Code: Bestehenden Code nachträglich mit Tests zu versehen ist aufwändig — aber lohnt sich langfristig. Refactoring hilft hier schrittweise.
  • Lernkurve: TDD erfordert Übung. Die ersten Wochen fühlen sich langsam an — das ändert sich, sobald der Zyklus in Fleisch und Blut übergeht.