Voorbereiding
1. Introductie
1.1. Behaviour Driven Development
In les 1 hebben we gekeken naar wat BDD (Behaviour Driven Development) is en wat het doel is dat we daarmee willen bereiken.
Het doel van BDD praktijken is voornamelijk om gedurende de hele levenscyclus van het product de wensen en eisen van de stakeholders te kunnen volgen in nauwe afstemming met het hele Agile-team, dat is inclusief bedrijfsanalisten, ontwikkelaars, QA-managers en testers.
Een veelgebruikt formaat binnen de toepassing van gedrag gedreven ontwikkeling (BDD) is om de wensen en eisen formeel vast te leggen in Gherkin features en scenarios. Dit Gherkin formaat is zo ontworpen dat het makkelijk begrepen kan worden door het hele Agile-team en tegelijk makkelijk te automatiseren is met BDD tools zoals Cucumber.
In Gherkin zijn de requirements gerelateerd aan een specifieke feature gegroepeerd in één bestand, dat wordt ook wel een feature file genoemd. Zo'n bestand bevat een korte beschrijving van de feature, gevolgd door een aantal scenario's of formele voorbeelden van hoe het feature dient te werken.
1.2. Voorbeeld Gherkin feature
Hieronder een voorbeeld van een feature met scenario's in Gherkin formaat voor het serveren van koffie:
Functionaliteit: Serveren koffie
Als een dorstige
Wil ik een kop koffie ontvangen
Zodat ik mijn dorst kan lessen
Scenario: kop koffie halen
Gegeven dat er koffie beschikbaar is
En er een beker in de koffiehouder zit
Wanneer de dorstige de keuze maakt voor koffie
Dan krijgt de dorstige een kop koffie geserveerd in de beker
Scenario: kop koffie halen zonder beker
Gegeven dat er koffie beschikbaar is
Wanneer de dorstige de keuze maakt voor koffie
Dan wordt de dorstige erop gewezen dat er een beker geplaatst moet worden
Scenario: kop koffie halen zonder beschikbare koffie
Gegeven dat er geen koffie beschikbaar is
En er een beker in de koffiehouder zit
Wanneer de dorstige de keuze maakt voor koffie
Dan wordt de dorstige verzocht om onderhoud te laten uitvoeren
Het is voor iedereen in het team in één oogopslag duidelijk wat hier gevraagd wordt, welk gedrag vereist is en welk doel bereikt moet worden.
1.3. Doel van de Gherkin syntax
Het doel achter het ontstaan van de Gherkin syntax is om gedrag gedreven ontwikkeling (BDD) mogelijk te maken door gedrag vast te leggen in formele scenario's. Doordat iedereen werkt met dezelfde definitie van (on)gewenst gedrag van eerste idee tot en met realisatie worden stevige, ondubbelzinnige eisen (acceptatiecriteria) afgedwongen in alle fasen van de ontwikkeling.
Kortom de som van alle features documenteren gezamenlijk de functionele requirements van het systeem en vormen de specificatie van het product. Wanneer de scenario's uit deze features door middel van specifieke tooling ook als test uitgevoerd kunnen worden noemen we dat ook wel een executeerbare specificatie.
Schrijf geen geautomatiseerde (acceptatie) testen, maar schrijf een executeerbare specificatie (van gedrag).
2. Gedrag gedreven ontwikkeling (BDD)
Het BDD proces is samen te vatten in 6 stappen die gedurende de levensduur van het product (iteratief en incrementeel) doorlopen worden.
We zullen in de komende les inzoomen op de eerste 3 fases van dit stappenplan en de lessen daarop kijken naar de implementatie, automatisering (verificatie) en rapportage (demonstratie/validatie).
2.1. Elicitatie van het domein en de verwachtingen van stakeholders
Voor de elicitatie hebben jullie geleerd om gebruik te maken van Domain Storytelling. Al zijn er natuurlijk ook andere methoden, want denk bijvoorbeeld nog maar eens terug aan wat jullie bij Functional Analysis en Testing (FAT) in de propedeuse geleerd hebben (BPMN, BCD en Use Case Model). Allemaal met als voornaamste doel om goed scherp te krijgen wat de stakeholders nu precies willen en bedoelen in terminologie van het domein.
Neem nooit blind over wat de domeinexpert je vertelt!
2.2. Refinement van functionaliteit tot een planbare eenheid van werk
Vervolgens kan bijvoorbeeld User Story Mapping toegepast worden om individuele User Stories (features) in kaart te brengen en daarmee prioriteit te geven aan de gespreksonderwerpen in verdere elicitatie. Dat iteratieve proces noemen we ook wel de refinement van de context en de wensen/eisen van de functionaliteit. Dit doe je net zolang totdat een planbare eenheid van werk is ontstaan.
Het mooie van User Stories is dat je ze kunt gebruiken als uitgangspunt voor Gherkin features om daarmee de functionaliteit van het systeem te specificeren.
Feature: <functie (werkwoord + zelfstandig naamwoord)>
Als een <actor> ❶
Wil ik <iets> ❷
Zodat <ik een bepaald doel kan bereiken> ❸
- ❶ Wie zal er profijt hebben van deze functionaliteit? Wie wil het?
- ❷ Wat doet deze functie?
- ❸ Welke (bedrijf) waarde zal de stakeholder uit deze functie halen?
2.3. Formuleren van concrete voorbeelden representatief voor (on)gewenst gedrag
Op basis van een feature (User Story) kunnen concrete voorbeelden in kaart gebracht worden middels een Example Mapping sessie met daarin aandacht voor:
- Welke verschillende uitkomsten kan de actor (gewenst of ongewenst) bereiken met deze functionaliteit?
- Welke verschillende acties kan de actor ondernemen in het systeem, in welke volgorde en wat is daarvan het gevolg?
- Welke verschillende startpunten zijn er mogelijk in het systeem bij deze functionaliteit?
- en wat betekent dat voor de acties en uitkomsten?
Deze voorbeelden kunnen opgeschreven worden in de vorm van Gherkin scenario's om zo het gewenste gedrag van het systeem te specificeren.
Elk Gherkin scenario bestaat uit een aantal stappen, waarbij elke stap begint met een van de Gherkin trefwoorden (Gegeven, Wanneer, Dan, En, Maar). De basis volgorde van een scenario is Gegeven... Wanneer... Dan...
De basis trefwoorden komen elk slechts één keer voor in een scenario, maar bij meerdere Gegeven/Wanneer/Dan stappen is het uitbreidbaar met En of Maar trefwoorden.
:::
Scenario: <doel van de actor>
Gegeven <begintoestand> ❶
Wanneer <stappen/acties> ❷
Dan <zou dit gebeurd moeten zijn> ❸
- ❶ Welke context of achtergrond is relevant bij dit voorbeeld?
- ❷ Welke actie wil je beschrijven?
- ❸ Welke uitkomst wordt er verwacht?
2.3.4. Overzicht van features
Het totaal van Gherkin features met bijbehorende (onderscheidende) scenario's geeft een beeld van het verwachte gedrag van het systeem. Kijk nog maar eens naar het voorbeeld van één feature voor de koffieautomaat in de introductie. Dit is een combinatie van User Story (feature) met concrete voorbeelden in de vorm van Gherkin scenario's.
3. Oefening met het maken van Gherkin scenario's
Maak Gherkin scenario's om te specificeren wat een systeem moet bijhouden voor een bowling game.
✏️ De instructies en casus informatie zijn hier te vinden <jouw repo van week 5>/weekopdracht/casusbeschrijving/README.md>.
Baseer de scenario's op een "Example Map" (zoals we geoefend hebben in les 1 van deze week).
User Story mapping voegt niet zoveel toe, omdat de gewenste feature al gegeven is.
Wanneer het allemaal nog een beetje duizelt kun je hoofdstuk 3 uit BDD in Action (Smart J.F., 2014) lezen ter verdieping. Dat hoofdstuk is opgenomen in de reader van DoEx.
Bronnen
- GherkinUFT.com (z.d.). BDD and Agile. Geraadpleegd op 29 mei 2024 van https://www.gherkinuft.com/gherkin/
- Smart J.F. (Maart 2023). BDD In Action. 2nd edition. Manning. https://www.manning.com/books/bdd-in-action