TDD, BDD en ATDD zijn termen die regelmatig terugkomen in een Agile omgeving. Ze zijn de afgelopen jaren steeds populairder geworden, maar veel organisaties kunnen het verschil of de overlap tussen deze concepten niet duiden. Zeker voor testers kan het verwarrend overkomen.

In dit artikel willen in het kort ingaan op wat Test Driven Development (TDD), Behaviour Driven Development (BDD) en Acceptance Test Driven Development (ATDD) is.

In volgende artikelen zullen we specifieker ingaan op de werkwijze van de verschillende aanpakken.

Wat is test first?

In een traditionele aanpak van softwareontwikkeling wordt eerst de code gemaakt en wordt er vervolgens getest. Testen wordt hierbij vaak laat in het proces uitgevoerd en het blijkt ook lastig te zijn om een goede testdekking te bereiken. Een “test first” aanpak kan dit veranderen. Hierbij worden eerst de testen opgesteld en pas daarna wordt de code ontwikkeld.

Er zijn verschillende “test first” aanpakken ontwikkeld. Deze worden ook wel aangeduid met X-driven development, waarbij de X staat voor de drijvende kracht. Bij TDD is dat de unittest, bij ATDD is dat de acceptatietest en bij BDD is dat het gedrag dat de gebruiker van de software verwacht.

TDD was de eerste “test first” aanpak. Het werd geïntroduceerd als een van de praktijken binnen Extreme Programming (XP) in de jaren negentig. Het wordt vooral gebruikt door ontwikkelaars voor de unit test.

Op enig moment kwam, uit Agile teams, de volgende vraag naar boven: Wat als we een manier zouden kunnen vinden om de voordelen van “test first” development ook te kunnen realiseren voor functionele testen en acceptatietesten? Toen ontstond ATDD. Later wilde Dan North het gedrag benadrukken vanuit een business perspectief en gaf zijn aanpak de naam BDD. ATDD en BDD zijn in de praktijk vergelijkbare aanpakken.

Test Driven development (TDD)

TDD is een methode waarbij, in kleine incrementele stappen, unit tests worden gemaakt, en in dezelfde kleine incrementele stappen wordt de code gemaakt om aan die tests te voldoen.

De volgende stappen worden steeds opnieuw uitgevoerd door de ontwikkelaar:

• schrijf een unit test die een aspect van het programma test
• voer de test uit, deze moet mislukken omdat in het programma de functionaliteit nog ontbreekt
• schrijf “net genoeg” code, zo eenvoudig mogelijk, om de test te laten slagen
• voer de unit test opnieuw uit
• als de test slaagt, ga dan verder met de volgende test, en anders herschrijf / wijzig de code om de test te laten slagen

Het resultaat is een volledig geautomatiseerde reeks unit tests. Deze unit tests zijn echter niet het doel. Het toepassen van TDD gaat meer over het van te voren bepalen van concrete en gedetailleerde verwachtingen over het gedrag van de code om op basis daarvan de code te ontwikkelen, dan dat het gaat om testen.

Acceptance Test Driven Development (ATDD)

Bij ATDD worden er, op basis van user stories, op een iteratieve manier testen opgesteld. User stories moeten requirements bevatten en deze requirements kunnen uitgewerkt worden in tests. Het opstellen van de tests is een gezamenlijk activiteit van business, ontwikkelaars en testers en vindt plaats in een specificatie workshop en voordat de code is ontwikkeld. Het doel van deze workshop is niet alleen het opstellen van de tests. Het belangrijkste doel is om gezamenlijk te komen tot een zelfde begrip van hoe de software wel / niet zou moeten werken. ATDD streeft er naar om de communicatie tussen business, ontwikkelaars en testers te verbeteren. De acceptatietests zijn dan ook een bijproduct.

Behaviour Driven Development (BDD)

BDD, zoals de naam al doet vermoeden, is een methode voor het ontwikkelen van een functie op basis van zijn gedrag. Het gedrag wordt in principe beschreven in de vorm van voorbeelden, in een zeer eenvoudige taal, die kan worden begrepen door iedereen in het team die verantwoordelijk is voor de ontwikkeling.

Het idee is om, samen met alle teamleden, vertegenwoordigers uit de business en mogelijk zelfs klanten, het gedrag van de software te definiëren. Dit kan op een gelijkaardige wijze gebeuren als bij ATDD, middels een specificatie workshop. De tests zijn dan gebaseerd op het verwachte gedrag en de ontwikkelaar voert deze tests iedere keer opnieuw uit na het ontwikkelen van nieuwe code.

Deelnemers aan de specificatie workshop krijgen de opdracht om na te denken over hoe het systeem zich moet gedragen en beschrijven dat volgens een vast formaat. Meestal wordt hierbij gebruik gemaakt van de Given-When-Then conventie. De Given-When-Then conventie staat centraal bij BDD. Het verbindt het menselijke concept van oorzaak en gevolg met het software concept van input-proces-output.