TDD + DDD = BDD

In vervolg op mijn vorige post over TDD vs DbC wilde ik verder uitleggen waarom ik vind dat TDD iets anders is dan alleen unit tests. Sterker nog: TDD heeft in het begin helemaal niets met unit tests te maken, volgens mij. In den beginne heb je namelijk nog helemaal geen units.

Bij het modelleren van een domein begin je namelijk typisch met uitspraken als: “Als een hypotheekaanbieder een voorwaarde stelt, dan geldt deze in principe altijd voor alle productlijnen en hypotheekproducten die deze aanbiedt, tenzij deze op één van deze lagere niveaus overschreven wordt” of “Als een bedrag van 20 euro van een rekening met 100 euro naar een pas geopende rekening overgeschreven wordt, dan bevindt zich, als alles goed gaat, 80 euro op de eerste rekening en 20 euro op de tweede na de overschrijving.”

Welke units gaat dit over? Juist, dit gaat over units heen. Hieruit gaan wellicht units volgen, maar op dit moment zijn ze er nog niet en uit deze uitspraken volgt het gebruik van meerdere units tegelijk, die samen bepaald gedrag vertonen. Dit is dan ook het uitgangspunt van behaviour driven development (BDD), dat probeert het originele TDD meer in lijn te brengen met DDD. Ja, leuk al die afkortingen. 🙂 De basis van het BDD proces bestaat uit de start met User Stories. Hieronder zie je een voorbeeld hiervan in een standaard formaat, uit de bovenstaande wiki overgenomen:

A SubjectMatterExpert (typically a business user) works with a BusinessAnalyst to identify a business requirement. This is expressed as a story using the following template:

As a Role
I request a Feature
To gain a Benefit

The speaker, who holds the Role, is the person who will gain the Benefit from the requested Feature.

Een dergelijke user story resulteert in verschillende scenarios, waarbij je gebruik kunt maken van de volgende template om deze scenario’s uit te werken:

Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

bron: http://dannorth.net/introducing-bdd

Het bovenstaande past heel goed bij het ontwikkelen van een domein model in een dynamische taal en bij uitstek in Smalltalk. Je kunt deze zinnen als methode naam kiezen en de tekst vervolgens gebruiken als basis voor de implementatie. Het bijzondere is dan natuurlijk dat de Smalltalk IDE je in staat stelt om het scenario direct uit te voeren en de classes en methodes ‘on the fly’ in te vullen tijdens het debuggen van het scenario. Het is dan ook niet toevallig dat we dat hier binnen Sogyo vaker doen…

Inmiddels zijn mijn gedachten over wanneer het handig is om in een dynamische taal te ontwikkelen en wanneer in een statische taal,  zich aan het refactoren (ik heb er weinig invloed op, dus voor zover ik weet doen de gedachten het zelf). Mijn voorlopige indruk is dat de ontwikkelingsfase van een domeinmodel in ieder geval een fase is waarin een dynamische taal veel voordelen biedt. Verdere lijken mij de dynamiek van het domein in kwestie en de noodzaak binnen het domein om runtime exceptions uit te sluiten, van invloed op de keuze voor een dynamische of statische taal, maar mijn ideeën daarover hebben zich nog niet helemaal gevormd.

Ik eindig even met een vraag: zou het misschien ideaal zijn om te beginnen in een dynamische taal om van buitenaf, black-box te kunnen specificeren middels BDD en nadien, als het model zich begint te ‘settelen’, vanaf de basis steeds meer DbC toe te passen, waarbij het gebruik van een statisch typeringssysteem daar dan volgens mij onder valt. Als ik denk het antwoord op deze vraag gevonden / gehoord te hebben, is het wellicht tijd voor een nieuwe blogpost!