Definition
Software-Entwicklungs-Praktik: erst Test schreiben (der zunächst fehlschlägt), dann Code zum Bestehen schreiben, dann Refactoring. Drei-Phasen-Zyklus „Red, Green, Refactor". Wirkungen: höhere Test-Coverage, robusteres Design, lebendige Dokumentation. Verzahnt sich gut mit CI/CD und Continuous Quality Practices. Wichtig in sicherheitskritischen Domänen (Avionik, Medizintechnik, Automotive) zur DAL-/SIL-Verifikationssicherung.
In der Praxis
TDD wird in den meisten Häusern zweimal falsch verstanden. Erstens als Aufgabe der Tester: TDD ist eine Entwicklerpraxis — der Test entsteht vor dem Code, von derselben Person, und steuert das Design. Zweitens als nachträgliche Testschreiberei: Wer erst codiert und dann Unit-Tests ergänzt, hat Testabdeckung, aber nicht die Wirkung von TDD — das vorausgeschriebene Testziel zwingt zu kleinen, prüfbaren Einheiten und entlarvt unklare Anforderungen, bevor eine Zeile Logik existiert. Dritter Stolperstein: Coverage als Selbstzweck. Neunzig Prozent Zeilenabdeckung mit belanglosen Tests sind schlechter als sechzig Prozent an den kritischen Pfaden. Und die Legacy-Ausrede: Gerade alter Code profitiert, wenn jede Änderung mit einem Charakterisierungstest abgesichert wird. Wichtig für regulierte Umfelder: TDD ersetzt nicht die geforderte, geplante Verifizierung nach IEC 62304 oder DO-178C — es ergänzt sie um Regressionssicherheit im Tagesgeschäft. Die Testfälle sind zugleich lebendige Spezifikation; das ist der Dokumentationsgewinn, den Audits zu schätzen lernen.
Häufige Fragen zu TDD
Was unterscheidet TDD von BDD und vom klassischen Testen am Ende?
Klassisches Testen prüft fertige Software gegen Anforderungen — es findet Fehler, nachdem sie eingebaut wurden. TDD dreht die Reihenfolge auf Modulebene um: Der Entwickler schreibt zuerst einen fehlschlagenden Unit-Test, dann den minimalen Code zum Bestehen, dann das Refactoring — der Zyklus dauert Minuten und wiederholt sich hundertfach am Tag. BDD hebt dieselbe Logik auf die fachliche Ebene: Statt Code-Einheiten werden Verhaltensweisen des Systems in natürlicher Sprache beschrieben und automatisiert — typischerweise von Fachlichkeit, Test und Entwicklung gemeinsam. Die Zuordnung: TDD sichert die technische Korrektheit der Bausteine, BDD das fachliche Verhalten des Ganzen, das klassische Testen bleibt für System-, Integrations- und Abnahmetests unverzichtbar. Wer TDD als Ersatz für den Systemtest verkauft, hat die Teststufen nicht verstanden.
Erkennt die IEC 62304 TDD als Verifizierungsmethode für Medizinprodukte-Software an?
Die IEC 62304 fordert einen definierten Software-Lebenszyklus mit geplanter Verifizierung: Software-Einheiten müssen gegen ihre Anforderungen geprüft, die Prüfungen dokumentiert und die Ergebnisse bewertet werden — abhängig von der Sicherheitsklasse der Software. Wie die Tests entstehen, schreibt die Norm nicht vor; TDD ist damit eine zulässige Arbeitsweise, solange die normativen Rahmenbedingungen erfüllt sind. Drei Punkte entscheiden: Die Verifizierung muss geplant und nicht nur emergent sein, die Testergebnisse müssen als dokumentierte Aufzeichnung vorliegen, und die Rückverfolgbarkeit von der Anforderung zum Test muss herstellbar bleiben. Genau daran scheitern reine TDD-Implementierungen im Audit — die Tests existieren, aber Planung und Rückverfolgbarkeit fehlen. Wer TDD in einen dokumentierten Verifizierungsplan einbettet, kombiniert beide Welten sauber (IEC 62304).
Wie führen wir TDD in einem Team mit gewachsenem Legacy-Code ein?
Nicht per Erlass und nicht für den Altbestand auf einmal. Starten Sie mit neuem Code: Jede neue Funktion entsteht testgetrieben, das ist der Lernmodus ohne Altlasten. Zweitens die Änderungsregel: Wer eine bestehende Stelle anfasst, schreibt zuerst einen Test, der das heutige Verhalten festschreibt — ein sogenannter Charakterisierungstest — und refaktorisiert erst dann. So wächst das Sicherheitsnetz genau dort, wo gearbeitet wird. Drittens die Infrastruktur: Die Tests laufen bei jedem Commit in der CI/CD-Pipeline, sonst verkommen sie zu Lippenbekenntnissen. Viertens die Qualifizierung: TDD ist eine Fertigkeit, die man am besten im Pairing oder Coding-Dojo lernt, nicht aus der Folien-Schulung. Rechnen Sie mit ein bis zwei Quartalen, bis der Rhythmus sitzt — und messen Sie den Erfolg an sinkenden Rework- und Fehlerquoten, nicht an der Abdeckungszahl.