Testgetriebene Entwicklung (TDD): Was sie ist und wie sie funktioniert

Testgetriebene Entwicklung (Test-Driven Development, kurz TDD) ist eine Art, Software zu bauen, bei der Entwickler einen kleinen automatisierten Test schreiben, bevor sie den Code für die Funktion schreiben. Diese neue Prüfung schlägt zunächst fehl, weil noch nichts gebaut wurde. Dann schreiben die Entwickler nur den Code, den der Test verlangt, räumen das Ergebnis auf und gehen zur nächsten Regel über.

Am Morgen des 5. Dezember 2025 legte ein kleiner Programmierfehler Shopify, Zoom, LinkedIn und die Websites mehrerer Banken lahm. Rund 25 Minuten lang sahen deren Kunden nur Fehlerseiten, wo eigentlich Bezahlvorgänge, Meetings und Kontostände hätten erscheinen sollen. Der Fehler steckte bei Cloudflare, dem Unternehmen, das den Datenverkehr all dieser Websites transportiert und schützt. Nach Cloudflares eigener Darstellung war der fehlerhafte Code viele Jahre lang unentdeckt geblieben, weil er nur in einer Situation ausgeführt wurde, die bis zu diesem Morgen nie eingetreten war.

Den Test zuerst zu schreiben, klingt verkehrt herum, hilft aber, Fehler in selten ausgeführtem Code zu finden. Bei TDD wird jedes Stück Code geschrieben, um einen Test zu bestehen, sodass selbst ein ungewöhnlicher Pfad durch das Programm vor dem Release ausprobiert wurde. Ein Test existiert allerdings nur für die Fälle, an die jemand gedacht hat. Jeder vorhandene Test bleibt im Projekt und läuft nach jeder Änderung erneut, wodurch TDD zur ersten Schicht des automatisierten Testens eines Produkts wird.

Lesen Sie weiter, um den Red-Green-Refactor-Zyklus, den Unterschied zu Behavior-Driven Development (BDD), die Rolle von KI und die Aufgabe von QA kennenzulernen.

Was ist testgetriebene Entwicklung?

Bei der testgetriebenen Entwicklung wächst das Produkt in kleinen Stücken, und jedes muss eine vorab geschriebene Prüfung bestehen. Die formale Definition stammt aus dem Glossar des International Software Testing Qualifications Board (ISTQB), das die Methode so beschreibt: „Ein Softwareentwicklungsverfahren, bei dem Testfälle entwickelt und automatisiert werden, und anschließend Software inkrementell entwickelt wird, um diese Testfälle zu bestehen.“

Der Softwareingenieur Kent Beck machte die Praxis 2002 mit seinem Buch Test Driven Development: By Example bekannt. Die Methode gehört den Entwicklern, und ihre Tests liegen direkt neben dem Produktcode. Jede Prüfung deckt ein einzelnes kleines Stück Logik ab, etwa die Berechnung einer Säumnisgebühr. Bevor ein Entwickler loslegt, notiert er meist die Fälle, die eine Funktion abdecken muss. Aus diesen Notizen werden dann nacheinander Tests.

Wie der TDD-Zyklus Red, Green, Refactor funktioniert

Entwickler nennen diesen Zyklus oft TDD Red Green Refactor, nach den Farben, die die meisten Testwerkzeuge anzeigen. Rot steht für einen fehlschlagenden Test, Grün für einen bestandenen. Stellen Sie sich eine Buchungs-App für einen Friseursalon mit einer Regel vor: Wer mindestens 24 Stunden vorher storniert, bekommt den vollen Betrag erstattet. Diese Regel entsteht in drei Schritten, die sich in einer Schleife wiederholen:

• Rot (Red): Der Entwickler schreibt zuerst einen Test, der eine Buchung 48 Stunden vor dem Termin storniert und die Erstattung des vollen Preises erwartet. Die Erstattungsfunktion gibt es noch nicht, also schlägt der Test fehl und das Werkzeug zeigt Rot. Dieser Fehlschlag beweist, dass der Test tatsächlich ein Problem erkennen kann.
• Grün (Green): Als Nächstes schreibt der Entwickler das absolute Minimum an Code, mit dem der Test besteht, so grob es auch aussieht.
• Refactoring (Refactor): Refactoring bedeutet, die Art zu verbessern, wie Code geschrieben ist, ohne zu ändern, was er tut. Wenn alle Tests bestehen, räumt der Entwickler auf: klarere Namen, keine doppelten Zeilen und eine einfachere Struktur. Die grünen Tests bestätigen anschließend, dass beim Aufräumen nichts kaputtgegangen ist.

Dann beginnt die Schleife mit einem zweiten Test von vorn: einer Stornierung drei Stunden vor dem Termin, die keine Erstattung bekommen soll.

Jeder Zyklus ist bewusst klein, sodass eine einzige Funktion Dutzende davon brauchen kann. Übrig bleibt am Ende ein Satz Unit-Tests: schnelle automatisierte Prüfungen, die jeweils ein Stück Code untersuchen. Teams ordnen Tests oft in einer Testpyramide an, mit vielen schnellen, kleinen Tests unten und wenigen langsamen Durchläufen ganzer User Journeys oben. Über Monate sammeln sich die Unit-Tests aus TDD zu Hunderten an und bilden die breite Basis dieser Pyramide.

Wenn Sie Code lesen, sehen die ersten beiden Schritte in Python mit pytest, einem verbreiteten Testwerkzeug, ungefähr so aus:

# Rot: zuerst geschrieben, schlägt fehl, weil refund_for() noch nicht existiert
def test_full_refund_when_cancelled_two_days_ahead():
    assert refund_for(hours_before=48, price=60) == 60

# Grün: der einfachste Code, mit dem der Test besteht
def refund_for(hours_before, price):
    return price

Die grüne Version ignoriert die 24-Stunden-Regel komplett, und das ist Absicht. Der Test mit der Stornierung drei Stunden vorher schlägt mit diesem Code fehl und zwingt den Entwickler, die eigentliche Erstattungslogik zu schreiben.

Warum TDD Shift-Left-Testing in seiner wörtlichsten Form ist

Shift-Left-Testing verlagert Qualitätsprüfungen näher an den Anfang eines Projekts. Dadurch werden Probleme kurz nach ihrer Entstehung gefunden. Teams erreichen das meist, indem sie Anforderungen früh prüfen und bei jeder Änderung automatisierte Tests ausführen. Testgetriebene Entwicklung treibt die Idee so weit, wie Code es zulässt. Jeder Test wird vor der Funktion geschrieben, die er abdeckt, sodass im Prinzip kein Produktcode ohne Test existiert.

Diese Reihenfolge verkürzt die Zeit zwischen einem Fehler und seiner Entdeckung auf wenige Minuten. Der Entwickler, der die fehlerhafte Zeile geschrieben hat, hat sie noch vor Augen, also ist die Korrektur eine Sache von Augenblicken. Taucht der Fehler erst in einer späteren Testrunde auf, muss jemand ihn reproduzieren, seine Ursache finden und Code ändern, den andere Funktionen vielleicht schon nutzen.

TDD vs. BDD: Wie sich die beiden Test-First-Methoden unterscheiden

BDD ist aus TDD hervorgegangen und behält die Test-First-Idee bei, richtet seine Tests aber an einen anderen Leser. Beim Vergleich TDD vs. BDD zählen vor allem vier Unterschiede:

• Wer die Tests liest: Entwickler schreiben TDD-Tests in einer Programmiersprache, vor allem für Kollegen, die ebenfalls programmieren. BDD-Szenarien sind Sätze in Alltagssprache nach dem Muster Given/When/Then (Gegeben/Wenn/Dann). Product Owner und Tester können diesen Text prüfen, ohne Code zu lesen.
• Wie viel ein Test abdeckt: Ein TDD-Test prüft eine kleine Regel im Code. Ein BDD-Szenario beschreibt ein vollständiges Verhalten, das ein Nutzer bemerken würde, zum Beispiel: „Gegeben ein Kunde, der sein Passwort vergessen hat, Wenn er einen Link zum Zurücksetzen anfordert, Dann kommt per E-Mail ein Link an, der nach einer Stunde abläuft.“
• Wie die Methoden zusammenpassen: Unter diesem Passwort-Szenario liegen mehrere TDD-Tests: Einer erzeugt den Link zum Zurücksetzen, einer setzt das Limit von einer Stunde durch, und einer lehnt jede zweite Verwendung ab. Teams, die beide Methoden kombinieren, arbeiten oft in zwei Schleifen und beginnen mit einem fehlschlagenden BDD-Szenario. Dann durchlaufen die Entwickler für jedes Teil TDD-Zyklen, bis das gesamte Verhalten funktioniert.
• Was jede Methode schützt: TDD schützt die interne Logik des Codes vor Fehlern. BDD sorgt dafür, dass die Menschen, die eine Funktion anfordern, und die Entwickler, die sie bauen, sich einig bleiben.

Die entscheidende Frage ist, wer die Tests lesen muss. Wenn das nur Entwickler tun, reicht TDD allein. Sobald Fachabteilungen das Verhalten von Funktionen abnehmen müssen, legt BDD eine lesbare Schicht darüber.

TDD im Vergleich zu Tests, die nach dem Code entstehen

Die übliche Alternative zu TDD ist Test-After-Entwicklung, bei der Programmierer zuerst eine Funktion bauen und Tests ergänzen, sobald der Code funktioniert. Beide Methoden können am Ende eine ähnliche Anzahl an Tests haben. Die Reihenfolge verändert jedoch, was diese Tests prüfen und wie der Code ausfällt.

Testgetriebene Entwicklung bringt drei zentrale Vorteile:

• Saubereres Design: Wer vor dem Schreiben festlegt, wie eine Funktion genutzt wird, erhält einfacheren Code, dem der nächste Entwickler folgen kann.
• Ein dauerhaftes Sicherheitsnetz: Die gesammelten Prüfungen laufen weiter, während das Produkt wächst, sodass eine Änderung, die altes Verhalten bricht, sofort fehlschlägt.
• Schutz für riskante Regeln: Preise, Abrechnung und Berechtigungen erhalten eine Prüfung für jeden Fall, den der Entwickler aufgelistet hat.

Die Methode hat auch klare Kosten:

• Ein langsamerer Start: Tests vorab zu schreiben, kostet Zeit, bevor eine neue Funktion läuft.
• Schlecht geeignet für alten Code: Projekte ohne Tests müssen oft umgebaut werden, nur damit Testen überhaupt möglich wird.
• Blinde Flecken bei Optik und Bedienung: Layout und Benutzerfreundlichkeit kann eine kleine Prüfung auf Codeebene nicht beurteilen.

Sollte diese Funktion Test-First entstehen: vier Ja-Nein-Fragen und eine Skala von Tests danach bis Tests zuerst

Welche Rolle spielt KI in der testgetriebenen Entwicklung?

KI-Programmierassistenten und TDD arbeiten gut zusammen, solange jede Seite ihre eigene Aufgabe behält. Der Entwickler entscheidet, was der Code tun muss, und hält das in Tests fest. Der Assistent erzeugt dann Code, bis alle diese Tests bestehen. So sieht die Aufteilung bei einem Treueprogramm aus, in dem Kunden für jede vollen 10 $ Umsatz einen Punkt sammeln:

1. Der Entwickler schreibt die Tests. Ein Test erwartet 9 Punkte für eine Bestellung über 95 $, ein zweiter will 10 für genau 100 $, und ein dritter prüft, dass ein Kaffee für 9 $ keinen Punkt bringt.
2. Der Assistent entwirft den Code. Angenommen, sein erster Versuch rundet 95 $ auf 10 Punkte auf. Der rote Test meldet diesen Fehler innerhalb von Sekunden, und der Assistent korrigiert ihn.
3. Der Assistent schlägt zusätzliche Fälle vor. Er fragt zum Beispiel, was nach einer Rückerstattung mit den Punkten passiert oder bei einer Bestellung, die mit einer Geschenkkarte bezahlt wurde. Der Entwickler entscheidet, welche dieser Fälle zur Regel gehören.
4. Der Entwickler prüft das Ergebnis. Dazu gehört, sich zu vergewissern, dass die ursprünglichen Tests unangetastet geblieben sind.

Die Aufteilung funktioniert nicht mehr, wenn der Assistent sowohl die Tests als auch den Code schreibt. Versteht das Werkzeug die Regel falsch, stimmen seine Tests mit seinem eigenen Fehler überein, und jede Prüfung besteht trotzdem. Ein Assistent kann einen roten Test auch grün machen, indem er ihn aufweicht, etwa indem er den Fall mit 95 $ löscht. Deshalb sollten Menschen die Tests schreiben und freigeben, auch wenn ein KI-Werkzeug den Großteil des Codes erzeugt.

Wo hat QA neben TDD ihren Platz?

TDD-Tests zeigen, dass der Code tut, was sein Entwickler beabsichtigt hat. Sie können aber nicht aufdecken, ob die Anforderung richtig verstanden wurde, weil dieselbe Person den Test und den Code schreibt. Angenommen, eine kostenlose Testphase soll 14 Kalendertage dauern, und der Entwickler versteht darunter 14 Arbeitstage. Test und Code stimmen dann perfekt überein, und beide sind falsch.

Starkes TDD bedeutet, dass weniger grundlegende Logikfehler bei den Testern ankommen. Ein QA-Team kann sich dann auf die Risiken konzentrieren, die außerhalb der eigenen Tests eines Entwicklers liegen:

• Anforderungen vor dem ersten Test: Zu Projektbeginn prüfen QA-Ingenieure die Anforderungen und Akzeptanzkriterien, also die Checkliste, die festlegt, wann eine Funktion fertig ist. Die Spezialisten von QAwerk prüfen außerdem die Testliste der Entwickler auf fehlende Fälle, etwa einen Kunden, der sich zweimal mit derselben E-Mail-Adresse registriert. TDD allein kann diese Lücken nicht schließen, da jeder Test von der Lesart einer einzigen Person ausgeht.
• Verbindungen zwischen Funktionen: Integrationstests prüfen, wie sich einzelne Teile verhalten, sobald sie zusammengefügt sind. Eine bestätigte Zahlung sollte zum Beispiel das Abo des Kunden aktivieren. Ein TDD-Test kann diese Verbindung meist nicht prüfen, da er ein Stück Code isoliert untersucht.
• Timing und reale Bedingungen: QA-Ingenieure testen das laufende Produkt so, wie Menschen es tatsächlich nutzen. Zwei Kunden könnten zum Beispiel gleichzeitig dieselbe Bestellung bearbeiten, während das Netz langsam ist. Unit-Tests stellen diese Situation selten nach, weil sie in Sekunden auf einem einzigen Rechner laufen.
• Benutzerfreundlichkeit: Beim explorativen Testen bewegt sich ein Tester frei und ohne Skript durch die App. Dabei fällt dem Spezialisten vielleicht auf, dass Kunden den Button zum Stornieren nur schwer finden. Keine Prüfung auf Codeebene kann das beurteilen, denn Verwirrung ist eine menschliche Reaktion.

Passt TDD zu Ihrem Produkt?

Mit testgetriebener Entwicklung dauert es anfangs länger, jede neue Funktion zu bauen. Dafür wird jede Regel, die das Team festlegt, mit ihrem eigenen Test ausgeliefert, und der Code bleibt leichter änderbar. Bei einem Produkt, das über Jahre wachsen soll, zahlt sich dieser Tausch meist aus.

Unsere QA-Ingenieure setzen dort an, wo diese Tests aufhören, von der Prüfung der Anforderungen vor der ersten Codezeile bis zu Integrations- und Usability-Tests an der fertigen Software. Diese Arbeit kann in der Planungsphase beginnen oder nach Jahren mit einer ausgereiften TDD-Testsuite.

Möchten Sie Ihre Testkapazitäten ausbauen? Rufen Sie uns noch heute an.

Häufige Fragen

Sehen Sie, wie wir Kazidomi geholfen haben, die Bereitstellung neuer Funktionen mit Testautomatisierung zu beschleunigen und zum Startup Nr. 1 in Belgien zu werden

Bitte geben Sie Ihre Geschäfts-E-Mail ein ist keine Geschäfts-E-Mail

Fallstudie erhalten