Test-Driven Development

Was TDD ist — und warum es Disziplin verlangt

Test-Driven Development (TDD) ist eine Vorgehensweise, die die übliche Reihenfolge umkehrt: Zuerst wird der Test geschrieben, dann der Code, der ihn erfüllt. Was wie ein kleines Detail klingt, verändert die Art, wie Software entsteht — und am Ende ihre Architektur.

Die Methode wurde Ende der Neunziger im Umfeld von Extreme Programming geprägt und 2003 von Kent Beck in „Test-Driven Development By Example" zur Disziplin verdichtet. Drei Regeln, später von Robert C. Martin als „Three Laws of TDD" formuliert, bilden den Kern:

1. Schreiben Sie keinen Produktionscode, bevor nicht ein fehlschlagender Test existiert.
2. Schreiben Sie nicht mehr Test, als nötig ist, um den Test fehlschlagen zu lassen.
3. Schreiben Sie nicht mehr Produktionscode, als nötig ist, um den Test grün zu machen.

Auf den ersten Blick wirkt das pedantisch. In der Praxis ist es ein Disziplin-Anker: Wer sich daran hält, schreibt automatisch in kleinen Schritten, in testbaren Einheiten, mit klaren Verträgen.

TDD ist dabei nicht gleichbedeutend mit „Tests schreiben". Tests nach dem Code sind eine vernünftige Praxis und keine Schande — aber sie sind nicht TDD. Der Unterschied liegt im Werkzeugcharakter: Im Test-First-Ansatz ist der Test das Mittel zum Entwurf. Im Test-After-Ansatz ist er Absicherung. Beides hat Wert, aber nur das erste verändert, wie der Code aussieht.

In den letzten Jahren hat sich der Kontext verschoben. Continuous Integration, Continuous Deployment und kurze Release-Zyklen verlangen Tests, die in Sekunden laufen und in Minuten Vertrauen erzeugen. Mit KI-gestützter Entwicklung — Code-Vervollständigung, Agenten, Pair-Programming-Assistenten — kommt ein zusätzlicher Hebel hinzu: Generierter Code ist nur so verlässlich wie die Tests, gegen die er antritt. Wer Tests zuerst schreibt, hat ein Sicherheitsnetz für genau diese Art der Produktion — egal, ob ein Mensch oder ein Modell den Code beigesteuert hat.

Der Red-Green-Refactor-Zyklus

Der Zyklus läuft in drei Phasen, die einander schnell ablösen. Eine Iteration dauert typischerweise wenige Minuten — wer eine halbe Stunde am Stück „im Grün" ist, hat den Rhythmus verlassen.

1. RED — den Test schreiben, der fehlschlägt

   Beschreiben Sie das gewünschte Verhalten als Test. Nicht „der Code, den ich gleich schreibe", sondern „das Verhalten, das der Code haben soll". Der Test schlägt fehl — gut so. Der rote Balken ist die Bestätigung, dass der Test überhaupt etwas prüft. Ein Test, der von Anfang an grün ist, prüft entweder nichts oder den falschen Zustand.

2. GREEN — der minimale Code, der den Test grün macht

   Nicht der schöne Code, nicht der finale — der kleinste, der den Test bestehen lässt. „Fake it till you make it" ist hier explizit erlaubt: Wenn ein hartcodierter Rückgabewert reicht, dann reicht er. Die Versuchung, gleich elegant zu schreiben, ist groß und kontraproduktiv. Sie führt zu Code, der zu viel auf einmal versucht — und damit das Falsche tut.

3. REFACTOR — aufräumen ohne Verhaltensänderung

   Erst jetzt wird der Code in Form gebracht: Duplikate beseitigen, Namen schärfen, Verantwortlichkeiten trennen. Die Tests sind dabei der Schutzschirm — sie melden sich sofort, wenn das Refactoring das Verhalten verändert. Wer diese Phase überspringt, baut technische Schulden auf, die der nächste Zyklus nicht mehr trägt.

Der Zyklus am konkreten Beispiel

Eine kleine Funktion, die einen Eurobetrag im deutschen Format ausgibt, zeigt den Ablauf. Beginn mit dem ersten fehlschlagenden Test:

// RED — Test schreiben, der mangels Implementierung fehlschlägt
test('formatiert positive Beträge mit zwei Nachkommastellen', () => {
  expect(formatPrice(12.5)).toBe('12,50 €');
});

Der Test schlägt fehl — formatPrice existiert nicht. Jetzt die minimale Implementierung, gerade so viel Code, dass der Balken grün wird:

// GREEN — minimal, ohne Eleganz
export function formatPrice(value: number): string {
  return value.toFixed(2).replace('.', ',') + ' €';
}

Tests grün. Erst jetzt wird der Code refaktoriert — Verhalten unverändert, aber lesbarer:

// REFACTOR — Lesbarkeit erhöhen, Tests bleiben grün
export function formatPrice(value: number): string {
  const formatted = value.toFixed(2).replace('.', ',');
  return `${formatted} €`;
}

Der nächste Zyklus beginnt mit dem nächsten Verhalten: negative Beträge, Tausender­trennzeichen, sehr große Zahlen, ungültige Eingaben. Jedes neue Verhalten ist ein neuer Test, der erst rot und dann grün wird — und nach jedem grünen Balken ist die Refactor-Frage erlaubt: Lässt sich das schöner schreiben, ohne das Verhalten anzufassen?

Vorteile in der Praxis

TDD wirkt nicht als einzelner Effekt, sondern entlang mehrerer Dimensionen. Vier davon sind in Projekten regelmäßig nachweisbar:

Die Vorteile sind kumulativ — der größte Effekt entsteht erst, wenn alle vier zusammenwirken. Code mit hoher Coverage, der nicht entkoppelt ist, bleibt trotzdem unwartbar; eine entkoppelte Architektur ohne Tests verliert ihre Struktur in der ersten Iteration. TDD ist deshalb keine Optimierung am Detail, sondern ein anderes Vorgehen mit anderem Ergebnis.

Ein zweiter, oft unterschätzter Effekt ist Geschwindigkeit nach drei Monaten. Im ersten Monat ist TDD spürbar langsamer als „erst Code, dann vielleicht Test". Im zweiten Monat gleicht sich das Tempo aus, weil weniger Debugging-Zeit anfällt. Ab dem dritten Monat ist TDD schneller, weil Refactoring nicht mehr Tage, sondern Minuten kostet — und genau dann beginnt die eigentliche Investition zu zinsen.

In regulierten Umgebungen kommt ein weiterer Vorteil hinzu, der außerhalb der reinen Engineering-Argumente liegt: Tests sind belastbare Audit-Artefakte. Ein Test, der eine Berechnungsregel exakt formuliert und automatisiert prüft, beantwortet im Audit eine Frage präziser als jede Spezifikation in Prosa — und er bleibt aktuell, weil er bei jeder Codeänderung mitläuft. Wo Fachbereich, Aufsicht und Entwicklung dieselbe Sprache sprechen müssen, wird der Test zum gemeinsamen Vertragstext.

Was TDD nicht ist

Vier Missverständnisse halten sich hartnäckig und bremsen Teams, die sich der Methode nähern. Sie auszuräumen ist die Vorbedingung dafür, dass die Diskussion über TDD nüchtern geführt werden kann.

• TDD ist keine Garantie für Bug-Freiheit. Tests prüfen Verhalten gegen Erwartungen. Wenn die Erwartung falsch ist, ist auch der Test falsch. TDD reduziert die Klasse der mechanischen Fehler — Konzeptfehler bleiben.
• TDD ist nicht „alles testen". Coverage als Selbstzweck führt zu Tests, die nichts prüfen außer ihrer eigenen Existenz. Die richtige Frage lautet: „Welches Verhalten ist wichtig?" — nicht: „welche Zeile ist noch ohne Test?".
• TDD ersetzt keine Architektur-Arbeit. Die großen Strukturentscheidungen — Modul-Schnitt, Bounded Contexts, Daten-Modell — entstehen nicht im Test, sondern im Vorab-Denken. TDD wirkt im Kleinen, Architektur im Großen.
• TDD funktioniert nicht für jede Art von Code. UI-Animationen, explorative Algorithmen-Forschung, einmalige Datenmigrationen, Wegwerf-Prototypen — hier ist das Verhältnis aus Aufwand und Nutzen oft schlecht. Disziplin heißt auch, zu wissen, wann sie nicht trägt.

Stolpersteine in der Praxis

Wo TDD scheitert, liegt es selten an der Methode. Fünf wiederkehrende Probleme erklären die meisten Fälle:

• Brittle Tests. Tests, die an die Implementierung gekoppelt sind statt an das Verhalten. Jedes Refactoring bricht zwanzig Tests — und das Team beginnt, Tests als Last zu empfinden. Heilmittel: über öffentliche Schnittstellen testen, nicht über Implementierungsdetails. Mocks sparsam, nur an System­grenzen.
• Test-Pyramide kaputt. Zu viele langsame Integrationstests, zu wenige schnelle Unit-Tests. Die Suite läuft 20 Minuten — niemand startet sie noch vor dem Commit. Heilmittel: Pyramide bewusst auf rund 70 % Unit, 20 % Integration, 10 % End-to-End ausrichten und konsequent verteidigen.
• Test-Doubles-Chaos. Mocks, Stubs, Fakes und Spies wild gemischt, jedes Team-Mitglied mit eigener Vorliebe. Hilfreich ist eine kurze Übersicht: Stubs liefern feste Antworten, Fakes sind funktionierende, aber vereinfachte Implementierungen (z. B. eine In-Memory-Datenbank), Mocks prüfen Interaktionen (wurde diese Methode mit diesen Argumenten gerufen?), Spies zeichnen Aufrufe auf, ohne Verhalten zu ersetzen. Heilmittel: eine Bibliothek (Mockito, Sinon.js, NSubstitute) und ein paar gemeinsame Konventionen, durchgesetzt im Code-Review.
• TDD als Dogma. Wer mit dem Hammer kommt, sieht überall Nägel. Auch innerhalb eines Projekts gibt es Bereiche, in denen TDD trägt, und Bereiche, in denen es nicht trägt. Beides anerkennen, beides explizit machen.
• Disziplin-Erosion unter Druck. Im Sprint-Endspurt fallen die Tests als Erstes. Heilmittel: Tests in der Definition of Done verankern, Code ohne Tests nicht mergen lassen — und im Notfall lieber Scope schneiden als Qualität.

Wann sich TDD lohnt — eine pragmatische Empfehlung

TDD ist keine universelle Antwort, sondern ein Werkzeug mit klarem Profil. Der ehrlichste Umgang damit ist, zu wissen, wann es sich lohnt und wann nicht.

Klar lohnenswert:

• Business-Logik mit klaren Verträgen — Berechnungen, Validierungen, Workflows, Entscheidungs­regeln.
• Regulatorisch sensible Pfade, in denen Audits nachvollziehen müssen, dass eine Regel implementiert wurde.
• Langlebige Plattformen, die über Jahre weiterentwickelt werden und mehrere Generationen von Entwicklern überdauern.
• Code mit hoher Komplexität, in dem manuelles Testen unverhältnismäßig wird.

Kaum lohnenswert:

• Prototypen, deren Lebensdauer in Tagen gemessen wird.
• UI-Code mit hohem visuellem Anteil — hier sind End-to-End-Tests und visuelle Snapshots oft sinnvoller.
• Forschungs-Code, dessen Ergebnis erst durch Iteration entsteht und dessen Anforderungen sich von Tag zu Tag ändern.

Der pragmatische Mittelweg: Kernlogik mit TDD; an den Rändern — Glue-Code, Adapter, Boilerplate — klassische Tests nach Bedarf; Prototypen ohne Tests, aber mit klarem Stop-Signal, ab wann sie zu Produktion werden. Genau dieser Übergang ist die Stelle, an der die meisten Schulden entstehen — und an der die Disziplin am wichtigsten ist.