Het primaire doel van BDD is om mensen te laten communiceren en de kloof te dichten tussen ‘technische’ en ‘business’ mensen. BDD zorgt voor communicatie tussen iemand met diepgaande technische kennis, iemand met een grondige business kennis en een professionele tester. Door deze verschillende stakeholders de functionaliteit te laten bespreken, de problemen te bespreken en te praten over hoe ze deze kunnen oplossen, zal leiden tot specificaties die door alle stakeholders op dezelfde wijze wordt begrepen.
BDD gebruikt Gherkin, een eenvoudige taal, om te beschrijven hoe een functie zich zal moeten gedragen onder verschillende omstandigheden.
Behaviour Driven Development (BDD) is een raamwerk voor software ontwikkel activiteiten. BDD is dus niet een tool, maar een werkwijze.
Uiteraard zijn er wel tools die BDD ondersteunen bij het uitwerken van een BDD Story en tools waarmee de testautomatisering van de scenario’s kan worden gerealiseerd. Sommige tools ondersteunen beide of hebben integratiemogelijkheden met andere tools.
Op basis van onderstaand plaatje zal de algemene opzet van deze tools worden geïntroduceerd.
BDD Story
Een BDD Story wordt vastgelegd in een .feature file en bestaat uit een feature deel, requirements, 1 of meerdere scenario’s en per scenario een aantal steps. Meer achtergrond informatie hierover kun je lezen op de pagina BDD Story.
Voorbeeld BDD Story
Title: Webshop bezoeker ziet gerelateerde producten bij bekijken product
As a product manager
I want dat een bezoeker van de webshop gerelateerde producten te zien krijgt bij een product
So that de omzet per order met minimaal 5% verhoogd wordt
Requirements:
- 2 gerelateerde producten worden getoond mits op voorraad
- Er worden willekeurig 2 producten getoond van de gerelateerde producten
- Gerelateerde producten die niet op voorraad zijn mogen niet worden getoond
- Wanneer er geen gerelateerde producten zijn, dan wordt er niets getoond
- Gerelateerde product mag niet het getoonde product zijn
- …
Scenario 1: Voorradige gerelateerde producten
Given het product heeft 2 voorradige gerelateerde producten [step]
When webshop bezoeker product bekijkt [step]
Then worden de 2 gerelateerde producten getoond [step]
Scenario 2: Geen gerelateerde producten
Given het product geen gerelateerde producten heeft
When webshop bezoeker product bekijkt
Then worden er geen gerelateerde producten getoond
Er zijn tegenwoordig meerdere tools die het beschrijven van een BDD Story ondersteunen. De volgende 5 zijn op dit moment veel gebruikte tools:
- Cucumber
- SpecFlow
- FitNesse
- Jbehave
- Behat
Testautomatisering
Om de scenario’s uit een BDD Story geautomatiseerd uit te kunnen voeren, moet er voor elke step uit de BDD Story een “step definition” zijn. Een “step definition” is een stuk software die het mogelijk maakt om de step uit te voeren. Daarnaast kunnen ze logica bevatten om de resultaten van een scenario te controleren en daarmee bepalen of de test goed of fout is gegaan.
Wanneer een scenario wordt uitgevoerd dan koppelt de tool elke step beschrijving, uit de BDD Story, aan een “step definition”. Er moet dus voor iedere step een “step definition” zijn.
Wanneer een step in een BDD story op meerdere plaatsen voor komt of misschien zelfs in meerdere BDD stories voor komt dan hoeft de “step definition” in principe maar een (1) keer te worden gemaakt.
Niet alle logica, die voor het geautomatiseerd uitvoeren van de scenario’s nodig is, kan met behulp van “step definitions” worden gerealiseerd. Denk hierbij bijvoorbeeld aan bepaalde settings van het systeem of het vullen van de database met testdata. De meeste BDD frameworks gebruiken hiervoor hooks. Deze worden gebruikt om software aan te roepen die de noodzakelijke acties uitvoert. Een hook kan aan het begin worden gebruikt om het systeem in de gewenste startsituatie te krijgen of aan het einde om de testomgeving te schonen.
Elk testautomatisering framework heeft een driver die de testen uitvoert. Een driver voert ieder scenario, uit de BDD Story, onafhankelijk van elkaar uit. Wanneer er iets fout gaat, dan wordt dit door de driver gerapporteerd en wordt het uitvoeren van het betreffende scenario gestopt. Vaak hebben drivers een mechanisme waarmee selectief scenario’s kunnen worden uitgevoerd.
De 5 hiervoor genoemde tools voor de BDD Stories ondersteunen verschillende programmeertalen.
- Cucumber
- Cucumber ondersteunt Ruby
- Cucumber-JVM ondersteunt Java en JVM
- Cucumber.js ondersteunt JavaScript
- Test::BDD::Cucumber ondersteunt Perl
- SpecFlow ondersteunt C# en .NET
- FitNesse ondersteunt Java, .Net, Ruby, PHP, Python, C#
- Jbehave ondersteunt Java en JVM
- Behat ondersteunt PHP
Daarnaast is het voor sommige tools mogelijk om te integreren met tools zoals:
- Selenium
- Watir
- Ruby on Rails
Welke is de beste?
Op deze vraag is geen eenduidig antwoord te geven. Het open deur antwoord is: de beste tool is degene die het beste past bij je behoefte 😉
Er is natuurlijk wel een aantal punten die meegenomen kunnen worden bij de afweging welke tool te gebruiken:
- Welke programmeertaal moet er gebruikt worden voor de testautomatisering?
- Wordt de tooling actief ondersteunt en verder ontwikkeld?
- Wordt de tool door veel verschillende bedrijven gebruikt?
- Wordt Gherkin volledig door de tool ondersteunt?
- Welke testsoorten moet de tool ondersteunen?
- ..
In de praktijk zal het er dus op neer komen dat er een toolselectie traject moet worden uitgevoerd.
Ook interessant?
Test first – Introductie tot X-driven development
Behaviour Driven Development (BDD)
Story opzet voor Behaviour Driven Development (BDD)
