jensjaeger.com

Nachdem in der Phase der Modellierung die Einordnung der Funktionalität ins Gesamtsystem erfolgt ist, folgt die Entwicklung der Tests. Dabei werden alle auf der zu bearbeiteten Storycard beschriebenen Funktionalitäten in Form in Tests umgesetzt. So entsteht aus der Storycard, vom Kunden oder Geschäftsseite verfasst, eine ausführbare Spezifikation der Funktionalität (vgl. Test Driven Development). Ausnahmen bilden Storycards die sich ausschließlich mit Verbesserungen der Oberfläche beschäftigen und keine Funktionalität des Systems verändern. Diese können aus einem Usability Test hervorgegangen sein und sind eventuell nur schwer oder gar nicht maschinell testbar. Dann wird die Phase Testdesign übersprungen.

Behaviour-Driven Development (BDD) ist eine Evolution des Denkens hinter Test Driven Development. Dabei wird die Sapir-Whorf Hypothese auf das Schreiben von Tests angewandt. Diese besagt: „zwischen den grammatikalischen Kategorien der Sprache, die eine Person spricht und wie diese Person die Welt versteht und sich in ihr bewegt, besteht eine systematische Beziehung“. Siehe Language, Thought and Reality. Selected Writings von Benjamin Lee Whorf.

Die Sapir-Worf Hypothese ist in der Linguistik umstritten. Unstrittig ist jedoch das Sprache unser Denkenin gewisser weise beeinflusst. Diese Aussage kann bis auf Wilhelm von Humboldts Essay „Über das vergleichende Sprachstudium“ von 1820 zurückgeführt werden.

Bei BDD wird im Vergleich zu TDD nicht ein Testfall definiert, sondern ein Erwartung. Das Ziel ist nicht eine Ansammlung von Tests sondern eine ausführbare Spezifikation der zu entwickelnden Software. Nach Astels „arbeitet man bereits mit BDD wenn man TDD richtig anwendet“. Es existieren spezielle BDD Frameworks die Softwareunterstützung für BDD bieten. BDD kann aber auch mit den bekannten xUnit Frameworks umgesetzt werden.

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: 

1. Rot - Schreibe einen Test für die nächste Funktion, der fehlschlagen muss.
2. Grün - Sorge mit möglichst wenig Quellcode dafür, dass wieder alle Tests laufen (grüner Balken für alle Tests).
3. 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.