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. 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!
