Test-Driven Development (TDD) ist eine Entwicklungspraxis, bei der vor dem Produktivcode automatisierte Tests geschrieben werden. Der klassische Zyklus lautet "Red - Green - Refactor": Zuerst wird ein fehlschlagender Test geschrieben (Red), dann der minimale Code zum Bestehen ergänzt (Green) und anschließend der Code refaktoriert, ohne die Tests zu brechen.
TDD wird auf Unit-Test-Ebene mit Frameworks wie xUnit, NUnit, JUnit oder Jest umgesetzt. Daneben existieren Varianten wie Inside-Out- und Outside-In-TDD oder Acceptance-Test-Driven Development (ATDD), in denen ausgehend von Akzeptanzkriterien getrieben entwickelt wird.
Einsatzzweck ist nicht nur die Erzeugung automatisierter Tests, sondern primär ein besseres Design: Wer in kleinen, prüfbaren Schritten arbeitet, wird gezwungen, lose Kopplung und klare Schnittstellen zu schaffen. Außerdem entstehen über die Zeit umfangreiche Regressionstests, die spätere Änderungen absichern.
TDD geht in seiner heutigen Form auf Kent Beck zurück, der es Ende der 1990er Jahre im Rahmen von eXtreme Programming wiederentdeckte und 2002 in dem Buch "Test-Driven Development: By Example" beschrieb. Beck selbst betont, dass die Idee - Tests vor dem Code zu schreiben - schon viel älter ist und auf Programmierpraktiken aus den 1960er Jahren verweist.
Bei bluehands gehört TDD zum Standard wird aber durch ATDD verdrängt. Agentic Coding verschiebt hier die Grenzen, da Test- und Produktionscode KI generiert werden.