ORDINA BLOGT

BDD deel III - (A)TDD

  • Kaspar van Dam
  • 2 mei 2016

Afgelopen week werd ik gebeld door een oud-collega die inmiddels werkzaam is bij een accountants kantoor waar hij bezig is om de Agile denk- en werkwijze te introduceren. Hij liep er tegenaan dat het lastig was om bepaalde minder concrete taken op te nemen op het SCRUM-bord. Men wist uit ervaring dat deze werkzaamheden iedere sprint langs zouden komen, uit ervaring was ook bekend hoeveel tijd dit ongeveer zou kosten per sprint. Maar wát de werkzaamheden precies zouden zijn kon weinig concreet gemaakt worden omdat het redelijk ad hoc werkzaamheden betrof. We kwamen er daarom op uit dat het verstandig was deze werkzaamheden als een algemene user story op het SCRUM bord te plaatsen en deze te timeboxen. SCRUM is namelijk een methodiek die een team moet helpen, niet een proces dat verplicht gevolgd moet worden en dat het team in de weg gaat zitten. Hetzelfde geldt voor BDD en (A)TDD. Het is een hulpmiddel, geen doel op zich!

BDD Deel III: (A)TDD

Het principe van eerst testen en dan coderen is zeer oud. Al midden jaren tachtig werd er gesproken van 'First test, then code' (zie: http://www.testingreferences.com/testingtimeline/testingtimeline.jpg). Maar ook op dat moment was het in feite niets nieuws. Onder de naam Test Driven Development is het de afgelopen jaren nieuw leven in geblazen.

Test Driven Development (TDD) wil zeggen dat er eerst een (technische) unit test gescreheven wordt. Deze zal falen bij gebrek aan werkende software. Daarna is het aan de software ontwikkelaar om de software te bouwen die de unit test laat slagen. Vervolgens kunnen via refactoring verbeterslagen doorgevoerd worden aan code of unit test waardoor deze weer zal falen en is het zaak te zorgen dat deze wederom slaagt. Enzovoorts. Bij Acceptance Test Driven Development (ATDD) begint men met het schrijven van een functionele acceptatietest. Ook deze zal falen bij gebrek aan software. De acceptatietest wordt gebruikt als basis voor het schrijven van de unit tests en vervolgens wordt de software geschreven om alle testen te laten slagen. Ook hier kunnen zaken verbeterd worden middels refactoring en is de cirkel rond. Dit principe is zichtbaar in onderstaande afbeelding.

ATDD principe

Maar wat heeft dit te doen met Behaviour Driven Development? In feite is ATDD en dus TDD niet meer dan een logische stap binnen BDD. Immers, middels Specifaction by Example (zie mijn vorige blog) hebben we zeer concreet gemaakt wat de specificatie is. Deze kan daarom 1 op 1 overgenomen worden als acceptatietest. Er is geen vertaalslag meer nodig en daarom verminderd ook het risico op een verschil in interpretatie. Zoals aangegeven gebeurt het specificeren van de concrete voorbeelden in een 3 amigo sessie voorafgaand aan het verdere software ontwikkelings traject en is er derhalve sprake van ATDD. Het vergt nu enkel nog enige discipline van het team om de feitelijke testgevallen om te zetten in features (bv. middels Cucumber) en deze daadwerkelijk te gebruiken als basis voor unit tests welke geschreven worden vóórdat de feitelijke software ontwikkeld wordt. Het resultaat is een efficiente manier van software bouwen waarbij het gedrag van de eindgebruiker centraal staat en waarbij dus gebouwd wordt waar de eindgebruiker werkelijk op zit te wachten: 'Building the right software'.

In mijn volgende, en laatste,  blog binnen het BDD vierluik zal ik verder ingaan op het belang van het feit dat iedereen binnen- en buiten het team dezelfde taal spreekt en dat dit gebruikt wordt als basis voor het gehele ontwikkelings proces.

Zoals altijd geldt: vragen? Op-/aanmerkingen? Hulp nodig bij het invoeren van BDD? Neem contact op met mij of de Ordina contactpersoon!

Over de auteur:

Kaspar van Dam

Kaspar van Dam is test(automatisering) consultant bij Improve QS en adviseert collega's en klanten over vraagstukken rondom de thema's Agile Testing, Behavior Driven Development (BDD), testautomatisering, performance testen en meer.