Test zuerst, dann Code

Was ist testgetriebene Entwicklung (TDD)?

TDD, Test-Driven Development

Testgetriebene Entwicklung ist eine Arbeitsweise, bei der du zu jeder neuen Funktion zuerst einen automatisierten Test schreibst, der fehlschlägt, und erst danach den Code, der diesen Test bestehen lässt. Der Ablauf wiederholt sich in kurzen Zyklen, die jeweils nur wenige Minuten dauern.

Kaum ändert jemand eine Zeile, bricht an anderer Stelle etwas weg. Tests zuerst zu schreiben ist die Antwort auf die Frage, wie du das früh genug merkst.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Zyklus: Rot, Grün, Refactoring
Taktlänge: Wenige Minuten pro Runde
Verwechselt mit: Nachträglich geschriebenen Unit-Tests
Braucht: Fachlogik, die ohne Infrastruktur aufrufbar ist

Der Zyklus aus Rot, Grün und Refactoring

Ein Durchlauf besteht aus drei Schritten. Zuerst schreibst du einen Unit-Test für ein Verhalten, das es noch nicht gibt, und lässt ihn laufen. Er muss rot werden, sonst prüft er etwas, das der Code ohnehin schon konnte. Im zweiten Schritt entsteht genau so viel Produktivcode, dass der Test grün wird, auch wenn die Lösung zunächst plump aussieht. Im dritten Schritt räumst du auf, ziehst Duplikate zusammen und benennst um, und 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.

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.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Testgetriebene Entwicklung und was oft damit gleichgesetzt wird

Testgetriebene Entwicklung gegen Unit-Test

Ein Unit-Test ist ein Werkzeug, testgetriebene Entwicklung eine Reihenfolge. Unit-Tests kannst du auch nachträglich schreiben, dann fehlt aber der Entwurfsdruck, weil die Struktur des Codes bereits feststeht.

Testgetriebene Entwicklung gegen Behaviour Driven Development

BDD hebt denselben Zyklus auf die fachliche Ebene und formuliert die Beispiele in einer Sprache, die Fachabteilung und Entwicklung gemeinsam lesen können. Der technische Ablauf bleibt gleich, die Beispiele sind gröber und beschreiben Verhalten statt einzelner Funktionen.

Testgetriebene Entwicklung gegen Testautomatisierung

Testautomatisierung besagt nur, dass Tests ohne Handarbeit laufen, unabhängig davon, wann sie entstanden sind. Ein Oberflächentest, der nachts über die fertige Anwendung läuft, ist automatisiert, hat mit TDD aber nichts zu tun.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Der Nutzen entsteht erst durch die Reihenfolge, nicht durch die Tests

In vielen Teams heißt testgetriebene Entwicklung in Wirklichkeit: Funktion fertigstellen, danach Tests nachziehen, damit die Abdeckung stimmt. Solche Tests bestätigen nur, was der Code ohnehin tut, samt der Fehler darin. Der eigentliche Gewinn liegt darin, dass du die Schnittstelle aus Sicht des Aufrufers festlegst, bevor dich eine halbfertige Implementierung in eine Richtung drängt.

Der zweite Stolperstein sind die Testebenen. Wer jeden Ablauf über Datenbank, Dateisystem und HTTP prüft, wartet Minuten auf jeden Durchlauf und bricht den Rhythmus ab. Damit der kurze Takt funktioniert, muss die Fachlogik ohne Infrastruktur aufrufbar sein, und in gewachsenen Systemen wird das oft erst nach einer sauberen Trennung der Zuständigkeiten möglich.

Und dann gibt es die Tests, die niemand mehr anfassen will: Sie prüfen interne Details statt Verhalten und schlagen bei jedem Umbau fehl, obwohl fachlich alles stimmt. Danach wird nur noch dort umgebaut, wo es keine Tests kostet, und der Rest bleibt liegen.

Testgetriebene Entwicklung lernen

Wie du Testfälle schneidest, Ergebnisse bewertest und eine Suite pflegst, die niemanden ausbremst, üben die Trainings zum Softwaretest an echtem Code.

Den Zyklus lernst du am schnellsten in einer Sprache, die du schon beherrschst, zum Beispiel in den Programmierkurse mit Python .

Kurse, die Testgetriebene Entwicklung behandeln

Häufige Fragen

Muss ich wirklich jeden Test vor dem Code schreiben?

In der reinen Lehre ja, im Alltag entscheidest du nach Risiko. Für Berechnungen, Sonderfälle und Zustandsübergänge zahlt sich die Reihenfolge fast immer aus. Bei Wegwerf-Prototypen oder beim reinen Verdrahten fremder Bibliotheken ist der Aufwand oft größer als der Ertrag.

Wie hoch sollte die Testabdeckung bei TDD sein?

Die Abdeckung ist eine Kontrollzahl, kein Ziel. Wenn du testgetrieben arbeitest, ergibt sich ein hoher Wert von selbst, weil keine Zeile ohne vorherigen Test entsteht. Eine feste Quote als Vorgabe führt dagegen schnell zu Tests, die Zeilen ausführen, ohne etwas zu prüfen.

Wird die Entwicklung dadurch nicht langsamer?

Der erste Durchlauf dauert länger, weil zwei Dinge entstehen statt einem. Die Zeit kommt beim Ändern zurück, sobald ein halbes Jahr später jemand eine Regel anpassen muss und die Suite in Sekunden sagt, was dabei kaputtgeht. Ohne Tests bezahlst du dieselbe Zeit später in der Fehlersuche.

Persönlich für dich da