Testgetriebene Entwicklung (TDD) ist eine Technik zum Erstellen von Software, die die Softwareentwicklung durch das Schreiben von Tests steuert. Es wurde entwickelt von Kent Beck in den späten 1990er Jahren als Teil von Extreme Programming. Im Wesentlichen befolgen wir wiederholt drei einfache Schritte:
- Schreiben Sie einen Test für die nächste Funktionalität, die Sie hinzufügen möchten.
- Schreiben Sie den Funktionscode, bis der Test bestanden ist.
- Refaktorieren Sie sowohl neuen als auch alten Code, um ihn gut zu strukturieren.
Obwohl diese drei Schritte oft als zusammengefasst werden Rot – Grün – Refaktor, das Herzstück des Prozesses sind, gibt es auch einen wichtigen ersten Schritt, bei dem wir zunächst eine Liste von Testfällen schreiben. Wir wählen dann einen dieser Tests aus, wenden den Rot-Grün-Refaktor darauf an und wählen, sobald wir fertig sind, den nächsten aus. Die richtige Reihenfolge der Tests ist eine Fähigkeit. Wir möchten Tests auswählen, die uns schnell zu den wichtigsten Punkten im Design führen. Während des Prozesses sollten wir weitere Tests zu unseren Listen hinzufügen, sobald sie uns einfallen.
Zuerst den Test schreiben, was XPE2 nennt sich Test-First-Programmierung und bietet zwei Hauptvorteile. Am offensichtlichsten ist es ein Weg, dorthin zu gelangen SelfTestingCode, da wir nur als Reaktion auf einen bestandenen Test Funktionscode schreiben können. Der zweite Vorteil besteht darin, dass wir, wenn wir zuerst über den Test nachdenken, zuerst über die Schnittstelle zum Code nachdenken müssen. Dieser Fokus auf die Schnittstelle und die Art und Weise, wie Sie eine Klasse verwenden, hilft uns, die Schnittstelle von der Implementierung zu trennen, ein Schlüsselelement guten Designs, mit dem viele Programmierer Probleme haben.
Ich höre am häufigsten, wie man TDD vermasselt, indem man den dritten Schritt vernachlässigt. Das Refactoring des Codes, um ihn sauber zu halten, ist ein wichtiger Teil des Prozesses. Andernfalls erhalten wir am Ende nur eine unordentliche Ansammlung von Codefragmenten. (Zumindest werden diese Tests durchgeführt, sodass das Ergebnis weniger schmerzhaft ist als bei den meisten Designfehlern.)
Weiterführende Literatur
Kents Zusammenfassung der kanonischer Weg, TDD durchzuführen
ist die wichtigste Online-Zusammenfassung.
Weitere Informationen finden Sie im Buch von Kent Beck
Testgetriebene Entwicklung.
Das relevante Kapitel von James Shore Die Kunst der agilen Entwicklung ist eine weitere gute Beschreibung, die es auch mit dem Rest der effektiven agilen Entwicklung verbindet. James schrieb auch eine Reihe von Screencasts mit dem Titel Lass uns TDD spielen.
Überarbeitungen
Mein ursprünglicher Beitrag auf dieser Seite war vom 05.03.2005. Inspiriert durch Kents kanonischen Beitrag habe ich ihn am 11.12.2023 aktualisiert