Hoe mooi zou het zijn om vanuit dit ideale plaatje van je klant precies te bouwen wat hij of zij vraagt. En hoe veel mooier zou het zijn als je dit automatisch kunt testen en op die manier de functionaliteit en kwaliteit van de applicatie kunt waarborgen en op een begrijpelijke manier inzichtelijk kunt maken.
Cucumber is de sleutel tot de oplossing. Op basis van de taal ‘Gherkin’ kunnen er gestructureerde scenario’s geschreven worden die deel uitmaken van een feature, oftewel functionaliteit. De syntax en opbouw van scenario’s in Gherkin zijn dusdanig simpel dat de gewenste functionaliteit voor iedereen begrijpelijk moet zijn. Hoe ziet dit er dan uit? De product owner vertelt:
As a ‘stakeholder’ (Given)
I want ‘a feature’ (When)
So I ‘meet some goal’ (Then)
Scenario: Daily solar panel output table
Given: I am logged in MySolarEnergy application
When: I click the SolarPanel button in the MySolarEnergy application
Then: I see the solar panel output table with daily values
Given: I am logged in MySolarEnergy application
When: I click the SolarPanel button in the MySolarEnergy application
Then: I see the solar panel output table with daily values
Oke, duidelijk verhaal, dit begrijpt iedereen die er aan werkt. Nu is het de kunst om daadwerkelijk BDD toe te passen. Aan elke regel in het in Gherkin geschreven scenario kan Java code ‘geglued’ worden. Dit doet Cucumber voor je, een plug-in die in je IDE geïnstalleerd kan worden. De testcode zorgt vervolgens dat de applicatie context goed gezet wordt (Given), er ‘op een knop’ gedrukt wordt (When) en gevalideerd of de gewenste uitkomst er is (Then).
In ons geval ziet dat er in Java als volgt uit:
@Given(“I am logged in MySolarEnergy application”)
public void iAmLoggedInMysolarenergyApplication() throws Throwable {
// TODO: code that logs user successful in MySolarEnergy application goes here.
}
public void iAmLoggedInMysolarenergyApplication() throws Throwable {
// TODO: code that logs user successful in MySolarEnergy application goes here.
}
Zodra ik dit voor alle stappen in het scenario heb gedaan is mijn testcode klaar. Ik kan de test als een jUnit test draaien in mijn IDE en ik zie dat deze faalt. Ik heb immers nog geen functionele code gebouwd. Daar is nu het moment voor: ik kan mijn test gebruiken om te valideren of ik mijn functionele doel heb bereikt tijdens het ontwikkelen. Trots wordt tijdens de Sprint Demo het resultaat aan de stakeholders gedemonstreerd. Ondanks dat ze blij zijn met de nieuwe functionaliteit wordt er kritisch opgemerkt dat de eenheden in de tabel in Wh zijn in plaats van kWh. Zijn de in Gherkin geschreven scenario’s wel concreet en technisch genoeg en is Cucumber hier de geschikte tool voor? Er kan gebruik worden gemaakt van een tabel om expliciete parameters te zetten of te valideren. Het scenario ziet er nu als volgt uit:
Scenario: Daily solar panel output table
Given: I am logged in MySolarEnergy application
When: I click the SolarPanel button
Then: I see the solar panel output table with daily values
| DateTime | Unit | Values |
| 12-07-2018 13:00:00 | kWh | 0.345 |
| 13-07-2018 13:00:00 | kWh | 0.543 |
Given: I am logged in MySolarEnergy application
When: I click the SolarPanel button
Then: I see the solar panel output table with daily values
| DateTime | Unit | Values |
| 12-07-2018 13:00:00 | kWh | 0.345 |
| 13-07-2018 13:00:00 | kWh | 0.543 |
Nu heeft de product owner een reden om blij te zijn. Het is duidelijk wat er gebouwd is. Als de Cucumber test groen is, werkt het zoals beschreven en er is levende documentatie van je product functionaliteit beschikbaar. Door de Cucumber features door je buildserver automatisch te triggeren bij bijvoorbeeld een PR kun je automatisch je functionaliteit blijven waarborgen en dit inzichtelijk maken aan de stakeholders.
