Was ist testgetriebene Entwicklung (TDD)?

Der Zyklus aus Rot, Grün und Refactoring

Ein Durchlauf besteht aus drei Schritten, benannt nach der Farbe, die das Testwerkzeug anzeigt. Die Methode geht auf Kent Beck zurück, der sie Ende der 1990er-Jahre im Umfeld von Extreme Programming bekannt machte und Anfang der 2000er in seinem Buch „Test-Driven Development: By Example“ beschrieb.

1. 1

   Rot

   Du schreibst einen Test für ein Verhalten, das es noch nicht gibt, und lässt ihn laufen. Er muss fehlschlagen, sonst prüft er etwas, das der Code ohnehin schon konnte.

2. 2

   Grün

   Es entsteht genau so viel Produktivcode, dass der Test besteht, auch wenn die Lösung zunächst plump aussieht. Alle bisherigen Tests müssen dabei grün bleiben.

3. 3

   Refactoring

   Du räumst auf, ziehst Duplikate zusammen und benennst um, ohne das Verhalten zu ändern. Nach jeder Änderung läuft die Testsuite erneut.

Die Schrittweite bestimmst du selbst. Bei einem vertrauten Problem darf ein Zyklus mehrere Zeilen umfassen, bei einer unklaren Anforderung schrumpft er auf einen einzigen Sonderfall, etwa auf eine leere Liste oder ein Datum am Monatsende. Wenn du länger als ein paar Minuten mit rotem Balken arbeitest, war der Schritt zu groß. Dann lohnt es sich, den letzten Stand zu verwerfen und kleiner neu anzusetzen.

Ein Beispiel in Python

Angenommen, ein Onlineshop soll ab 50 Euro Warenwert versandkostenfrei liefern, darunter kostet der Versand 4,90 Euro. Testgetrieben beginnst du nicht mit der Funktion, sondern mit zwei Tests, die mit pytest laufen. Beide schlagen zunächst fehl, weil es die Funktion noch nicht gibt.

# test_versand.py, Schritt Rot
from versand import versandkosten

def test_unter_grenze_kostet_versand():
    assert versandkosten(49.99) == 4.90

def test_ab_grenze_versandkostenfrei():
    assert versandkosten(50.00) == 0

# versand.py, Schritt Grün
def versandkosten(warenwert):
    return 0 if warenwert >= 50 else 4.90

Interessant ist der zweite Test: Er zwingt dich, die Grenze genau festzulegen. Gilt „ab 50 Euro“ einschließlich 50,00 Euro? Diese Frage stellt sich beim Schreiben des Tests, also bevor jemand sie im Betrieb an einer Reklamation entdeckt. Im Refactoring-Schritt würdest du die Zahlen 50 und 4,90 als benannte Konstanten herausziehen, und die Tests bestätigen, dass sich am Verhalten nichts geändert hat.

Was die Reihenfolge im Alltag bringt

Der eigentliche Gewinn liegt weniger im Netz aus Tests als im Entwurfsdruck. Wer den Test zuerst schreibt, ruft die Funktion von außen auf, bevor sie existiert, und merkt sofort, wenn eine Klasse fünf Abhängigkeiten mitschleppt oder eine Signatur unhandlich ist. Code, der schwer zu testen ist, fällt so am ersten Tag auf und nicht erst im Review.

Der zweite Effekt zeigt sich beim Ändern. Eine Suite, die in Sekunden durchläuft, macht Refactoring risikoarm, weil du nach jedem Schritt weißt, ob noch alles hält. Deshalb ist die Laufzeit kein Nebenaspekt: Sobald ein Durchlauf mehrere Minuten braucht, startet ihn niemand mehr ständig, und der Zyklus fällt in sich zusammen.

Fehler, die den Nutzen wieder auffressen

Am häufigsten begegnet dir der Test, der nie rot war. Entsteht er nach dem Code oder wird er nach einem Fehlschlag sofort zurechtgebogen, ohne dass jemand ihn hat scheitern sehen, kann er dauerhaft grün bleiben, obwohl er nichts prüft. Der rote Lauf gehört deshalb zum Verfahren und ist keine Zugabe.

Ebenso verbreitet ist der Test, der die Implementierung nachzeichnet statt das Verhalten. Prüft er, dass eine bestimmte Methode eines Mocks in einer bestimmten Reihenfolge aufgerufen wurde, bricht er bei jedem harmlosen Umbau. Solche Tests verhindern genau das, wofür der Zyklus gedacht war. Halte dich lieber an das Ergebnis, das nach außen sichtbar ist.