Test Driven Development: erst der Test, dann der Code

Test Driven Development (TDD) ist eine Entwicklungsmethode, bei der der Test vor der Implementierung geschrieben wird. Nicht als nachträgliche Qualitätskontrolle, sondern als Arbeitsmethode von Anfang an. Ein Test ist eine präzise, ausführbare Spezifikation: Bevor Sie Code schreiben, müssen Sie wissen, was der Code tun soll.

Das Problem vor dem Problem

Jedes Entwicklungsteam kennt diesen Moment: Ein Bugfix wird eingespielt, und drei Stunden später meldet sich ein Nutzer, weil ein anderer Bereich nicht mehr funktioniert. Niemand hat absichtlich etwas kaputt gemacht. Niemand hatte die Verbindung zwischen den beiden Stellen auf dem Schirm.

Regressionen sind kein Zeichen schlechter Entwickler. Sie sind ein Zeichen fehlender Absicherung. TDD setzt genau dort an.

Der Red-Green-Refactor-Zyklus

TDD läuft in drei Schritten ab, die ständig wiederholt werden:

Red: Sie schreiben einen Test für eine Funktion, die noch nicht existiert. Der Test schlägt fehl. Das ist beabsichtigt.

Green: Sie schreiben gerade so viel Code, dass der Test besteht. Nicht mehr. Keine spekulativen Features, keine vorauseilende Optimierung.

Refactor: Sie verbessern den Code, ohne sein Verhalten zu ändern. Die Tests laufen weiterhin durch und beweisen, dass nichts gebrochen wurde.

Dann beginnt der Zyklus von vorn.

Ein konkretes Mini-Beispiel

Angenommen, Sie bauen eine Funktion, die prüft, ob eine Zeichenkette eine gültige deutsche Postleitzahl ist.

Schritt 1 (Red): Test schreiben.

def test_gueltige_plz():
    assert ist_gueltige_plz("20099") == True
    assert ist_gueltige_plz("00000") == False
    assert ist_gueltige_plz("abcde") == False
    assert ist_gueltige_plz("1234")  == False

Die Funktion existiert noch nicht. Der Test schlägt fehl.

Schritt 2 (Green): Minimum implementieren.

import re

def ist_gueltige_plz(plz: str) -> bool:
    return bool(re.match(r'^[1-9]\d{4}$', plz))

Alle vier Testfälle laufen durch.

Schritt 3 (Refactor): Code ist kurz und lesbar. Kein Handlungsbedarf. Nächste Anforderung.

Welche realen Probleme TDD löst

Regressionen. Jede neue Funktion bringt einen Test mit. Über Monate wächst eine Testsuite, die alle abgedeckten Abläufe beschreibt. Änderungen, die etwas kaputt machen, werden sofort sichtbar.

Angst vor Refactoring. Viele Teams lassen alten Code unberührt, weil niemand weiß, was bricht, wenn man ihn anfasst. Mit einer belastbaren Testsuite fällt diese Angst weg.

Tests als lebende Dokumentation. Ein gut geschriebener Test beschreibt, was eine Funktion unter welchen Bedingungen tun soll. Das ist nützlicher als Kommentare, die schnell veralten.

Klarheit über Anforderungen. TDD zwingt Sie, vor der Implementierung zu entscheiden: Was soll diese Funktion zurückgeben? Welche Eingaben sind gültig? Welche Fehlerzustände gibt es?

Wann TDD sich nicht lohnt

• Explorative Arbeit und Prototyping: Wenn Sie noch nicht wissen, wie eine Schnittstelle aussehen soll, schreiben Sie den Prototyp ohne Tests. Wegwerfen ist erlaubt.
• UI-Code mit vielen visuellen Abhängigkeiten, solange das Design noch nicht feststeht
• Infrastruktur-Skripte, die einmalig ausgeführt werden

Die Faustregel: Je länger der Code lebt, je öfter er verändert wird und je mehr andere Teile von ihm abhängen, desto mehr zahlt sich TDD aus.

TDD und KI-generierter Code

KI-Werkzeuge generieren Code schneller, als er geprüft werden kann. Generierter Code tut oft das Offensichtliche, behandelt Randfälle und Fehlerzustände aber nicht immer korrekt.

TDD ist hier ein Sicherheitsnetz mit konkretem Wert: Sie beschreiben im Test, was der Code leisten soll. Der generierte Code muss diesen Test bestehen. Das verlagert die Qualitätsprüfung von “sieht plausibel aus” auf “besteht die Anforderung”. Teams, die heute verstärkt mit KI-Unterstützung entwickeln, berichten, dass ihre Testdisziplin entscheidend dafür ist, ob der Output nutzbar ist.

Erste Schritte im Team

• Beginnen Sie mit neuen Funktionen. Jede neue Logik bekommt einen Test vorher. Bestehenden Code nicht anfassen, außer wenn er ohnehin geändert werden muss.
• Setzen Sie eine niedrige Schwelle: zwei Tests pro Feature reichen zum Start.
• Machen Sie Tests zur Review-Pflicht. In Code-Reviews wird geprüft, ob zu jedem neuen Stück Logik ein Test existiert.
• Investieren Sie einmal in die Testinfrastruktur. Wenn Tests 20 Minuten brauchen, wird niemand sie während der Entwicklung ausführen. Ziel: Feedback unter 60 Sekunden für die relevante Suite.

Häufige Fragen

Wie lange dauert es, bis TDD die Entwicklungsgeschwindigkeit erhöht? In den ersten Wochen fühlt es sich langsamer an. Nach zwei bis drei Monaten mit wachsender Testsuite kehrt sich das um. Der Break-even liegt typischerweise bei drei bis vier Monaten, früher in Teams mit hoher Fehlerrate.

Muss ich den gesamten Bestand auf einmal umstellen? Nein. Bestehendem Code nicht anfassen, außer wenn er ohnehin geändert werden muss. TDD gilt ab sofort für alles Neue. Das ist realistisch und ausreichend.

Was ist der häufigste Fehler beim TDD-Einstieg? Zu große Tests schreiben. Jeder Test sollte genau eine Verhaltensanforderung prüfen. Wer drei Dinge in einen Test packt, weiß bei einem Fehlschlag nicht, was gebrochen ist.

Techiota baut Software und Automatisierungen für KMU in Hamburg, mit Testdisziplin als Teil der Bauweise. Wenn Sie wissen wollen, wie sich TDD in Ihren Entwicklungsprozess einfügen lässt, sprechen Sie uns an über techiota.de.