Test Driven Development (TDD) bezeichnet eine Methode zur Entwicklung von Software bei der Tests vor der eigentlichen Softwarekomponente entwickelt werden. Test Driven Development folgt dabei einem iterativen Prozess aus drei Schritten:
- Rot – Schreibe einen Test für die nächste Funktion, der fehlschlagen muss.
- Grün – Sorge mit möglichst wenig Quellcode dafür, dass wieder alle Tests laufen (grüner Balken für alle Tests).
- Refaktorisiere – Eliminiere alle Duplikationen und führe notwendige Abstraktionen ein.
Das Verlagern der Tests vor das Entwickeln von Softwarekomponenten bietet einige Vorteile. So wird die Spezifikation nach und nach in die Testsuite überführt. Daraus ergibt sich eine ausführbare Spezifikation, die in maschinell prüfbarer Form vorliegt. Es besteht weiterhin nicht die Gefahr das Tests, die beim klassischen Wasserfallmodel am Ende des Entwicklungsprozesses stehen, aus Zeitmangel nicht durchgeführt werden. Zusätzlich erleichtert eine Testsuite Refaktorisierungen massgeblich.
Kent Beck hat in Test Driven Development das Vorgehen anhand von Beispielen beschrieben und nennt ausführliche Test Patterns.
Hallo Jens,
Deine Erläuterungen zum Thema TDD sind sehr gut – ich stimme dem voll und ganz zu. Ich möchte noch etwas hinzufügen, was meiner Interpretation nach TDD noch bedeutet:
„TDD – it’s not about testing, it’s about writing better code“, Erik Doernenburg, http://erik.doernenburg.com
Ich vermittle meinen Entwicklern genau diese Idee. Neben der „red-green-refactor-mantra“ geht es darum Code so zu schreiben, dass er unabhängig, austauschbar, wiederverwendbar und natürlich testbar ist. Ich habe dazu auf meinem Blog einiges zusammengetragen:
http://inside-scrum.blogspot.com/search/label/TDD
Gruss, jp
Hallo jp,
danke für den hilfreichen Hinweis. Du hast vollkommen recht.
Gruß Jens