En Cucumber is ook geen testtool!

door | feb 15, 2020 | Blog

In een eerdere blog schreef ik dat Selenium
geen testtool is. Vandaag wil ik het hebben over een andere tool, die dat in
mijn ogen ook niet is.

Mijn eerste advies is ook hier: ga
naar de website, Cucumber.io. Hier staat: “Whether open source or commercial,
our collaboration tools will boost your engineering team’s performance by
employing Behavior-Driven Development (BDD).” Cucumber is dus een tool om
behavior-driven development te doen. Het biedt een taal waarin je met “Gherkin”
scenario’s kan beschrijven via de welbekende “given, when, then”
structuur. That’s it.

In alle projecten die ik heb gezien, wordt Cucumber naar binnen gerold als dé testautomatiseringstool, en niet om een BDD-vraagstuk op te lossen. Hierbij worden de mogelijkheden die Cucumber biedt eigenlijk misbruikt ten behoeve van de testautomatisering. En hier gaat het dan dus ook mis.

Een bepaalde mate van abstractie
kunnen toepassen is bij testautomatisering, net zoals bij het ontwikkelen van
software, erg belangrijk. Je wil namelijk in de meeste gevallen gelijksoortige
instructies niet dubbel (of tien keer) los uitschrijven. Cucumber biedt ook
abstractiemogelijkheden waarbij je bijvoorbeeld met variabelen kan aansturen wat
je Cucumber step precies doet. Probleem is alleen dat het abstractiedoel van
BDD hier vaak in strijd is met het doel van testautomatisering.

Een BDD-scenario zou, in ieder
geval naar mijn idee, business-driven moeten zijn. Geen technische, maar
business-termen. Een Given.. When.. Then.. scenario zou kort maar krachtig
moeten zijn. Bij testautomatisering is het juist vaak de bedoeling om in detail
te treden en bijvoorbeeld edge cases te testen. Als je gaat testautomatiseren
met Cucumber, dan leidt dat vaak tot eindeloos lange Cucumber-scripts die het
BDD-doel van uitvoerbare en leesbare specificaties voorbijschiet.

Cucumber heeft ook nog een ander
nadeel: het creëert namelijk een extra laag tussen de testautomatisering en het
Gherkin scenario. Los van het framework dat je gebruikt om de daadwerkelijke
aansturing van je applicatie te doen, zul je zogenaamde “glue code”
moeten schrijven die de Gherkin taal aan je testframework knoopt. Dit zorgt dus
altijd voor een extra laag tussen het testobject en het testscript, wat extra
complexiteit met zich meebrengt. En als je niet de vruchten plukt van het ‘BDD’
voordeel dat Cucumber je biedt, dan is deze extra complexiteit vrij snel
overbodig.

Als je Cucumber combineert met ‘vanilla’ Selenium, dan kan je ook alle nadelen van het gebruik van Selenium als testtool bij de eerder genoemde nadelen optellen (zie hiervoor mijn eerdere blog). En dan is het resultaat vaak een testframework dat slecht opgebouwd is, slecht werkt, slecht te onderhouden is en slecht uit te breiden is. Mijn advies is dus: doe het niet zo. Zoek een echte testtool! Mocht je daarentegen echt op een BDD-manier willen werken in je team, dan kan Cucumber een oplossing zijn. Maar zet het dan niet in als testtool! Ik geloof best dat Business Driven Development met Cucumber toegevoegde waarde heeft. Als je daar (goede) ervaringen mee hebt dan hoor ik er graag hieronder over!

0 reacties

Share This