Coen Klaas over Cucumber

| En waarom het meer is dan zomaar een testautomatiseringsmethodiek

Coen Klaas is sinds 2010 actief als testengineer bij opdrachtgevers in diverse branches. Sinds 2015 werkt hij bij Immune-IT. Hieronder het verhaal van Coen en Cucumber.

De laatste tijd hoor ik steeds vaker dat Cucumber wordt toegepast bij klanten van Immune-IT. Waarom? Is het een hype, of zitten er écht voordelen aan? Inmiddels werk ik zelf geruime tijd met Cucumber. Ik deel graag mijn ervaringen: welke voor- en nadelen heeft Cucumber?

Testautomatisering is in veel projecten een gekoesterde wens. De afgelopen jaren heeft dit dan ook veel aandacht gekregen. Vooral in continious delivery projecten brengen handige tools de nodige voordelen met zich mee. Wanneer je elke twee à drie weken oplevert, is het vaak onmogelijk om elke keer weer een complete regressietest handmatig uit te voeren, iets dat natuurlijk wel wenselijk is, aangezien je continu verbeteringen doorvoert die mogelijk de gehele applicatie raken. Al gauw wordt er dan gekeken naar de mogelijkheden van een geautomatiseerde regressietest. Cucumber is een van die vele testautomatiseringsmethodieken/tools waarmee aan deze wens kan worden voldaan.

Cucumber onderscheidt zich van andere tools omdat er minder vanuit de techniek wordt gedacht maar meer vanuit de business. De vraag “hoe kunnen wij er samen voor zorgen dat we een robuuste geautomatiseerde regressietest opzetten?”, staat centraal.

Krijg je het team niet op een lijn over de inhoud van de regressietest, dan zul je moeten kijken welke aanpassingen nodig zijn om dit wel voor elkaar te krijgen. Om deze regressietests te bepalen vindt er elke release een sessie plaats met één collega vanuit elke discipline van het team. Dit wordt een feature file refinement sessie genoemd. Tijdens deze sessie wordt in een paar regels kort en bondig beschreven welke functie precies getest gaat worden, wat deze doet als er een bepaalde actie wordt uitgevoerd en wat het gevolg is van deze specifieke actie. Deze regels tezamen worden een feature file genoemd.

De taal waarin de feature files worden geschreven heet Gherkin, Engels voor augurk. Dat klinkt spannender dan het is. Het is een taal die bedoeld is om voor iedereen leesbaar te zijn (met name ook de business). Dit is handig om de kloof tussen de IT en business zo klein mogelijk te maken, maar wanneer goed toegepast kun je de feature filesook gebruiken voor je documentatie.

Doordat er tijdens de feature file refinement sessies veel dieper op de stof wordt ingegaan en alles echt wordt uitgeschreven, merk je al gauw dat er veel vragen naar boven komen die tijdens de normale refinement sessie veelal onderbelicht blijven. Dat is een van de redenen dat developers ook graag bij deze sessies aanwezig zijn. Hieronder een kort voorbeeld van een feature file (dus geschreven in Gherkin) voor het bestellen van koffie uit de koffieautomaat.

Scenario: koffie uit de automaat bestellen
Gegeven: ik wil graag een kopje koffie
Als: ik op de automaat op de koffie-knop druk
En: ik geef de hoeveelheid melk aan
En: ik geef de hoeveelheid suiker aan
Dan: komt er koffie uit de automaat met de gewenste hoeveelheid melk en suiker

Goed te zien is dat Gherkin voor iedereen leesbaar is. Elke regel tekst heeft zijn eigen stuk code voor de actie en validatie. Dit kan onder andere in Java, .NET, Ruby en PHP. Wanneer er tijdens het draaien van de Cucumber tests iets fout loopt, wordt er exact aangegeven waar in de feature file de fout zit. Bijvoorbeeld wanneer de regel “En: ik geef de hoeveelheid suiker aan” is aangemerkt als fout, dan is mogelijk de functionaliteit om de hoeveelheid suiker te bepalen niet goed werkend.

Behavior-driven developement

Eerst wordt dus het gedrag beschreven, daarna tijdens de sprint achter elke Gherkin zin, de code. Deze aanpak heet ook wel behavior-driven development. Een term afkomstig uit de Agile software ontwikkelingstechniek. De koppeling met code is ook meteen een nadeel. De meeste testers hebben namelijk geen kennis van code en dat deel zal dus geschreven moeten worden door de ontwikkelaars, die ook al de unittests schrijven. Multidisciplinaire teams, waarbij iedereen de taak van zijn collega zou kunnen overnemen, zijn vaak niet zo multidisciplinair als dat wij zouden willen.

Waar ook rekening mee moet worden gehouden: tijdens het wijzigingen van de bestaande code om de kwaliteit van deze code te verbeteren (refactoring), komt het voor dat er een ontkoppeling plaatsvindt met de feature file(s).

In het begin ben je vooral zoekende naar hoe Cucumber het beste vorm gegeven kan worden binnen je project. Dat kost soms even tijd. Het is niet voor ieder project op maat geschreven. Het is continu proberen wat voor jouw team het beste aanvoelt. Dat lukt alleen maar met vallen en opstaan, dus wees vooral niet bang om iets te proberen, zo weet je namelijk steeds beter wat je wel en niet wilt.

Inmiddels is ons volledige team gewend om te werken met Cucumber en dit levert mooie resultaten op. De grootste voordelen? Een betere testdekking uiteraard, maar ook als teamspeler zie ik een groot voordeel in de mogelijkheden die de feature file refinement sessies  bieden tot een nog nauwere samenwerking tussen de teamleden. Wie had dat verwacht van een testautomatiseringsmethode?

Wil ook werken bij een werkgever die geïnteresseerd in jou als mens en in jouw toekomst wil investeren zodat jij ‘Fit for the Future’ wordt? Stuur je cv op en we plannen een kennismaking in.

(Oh ja, dit jaar bestaan we 10 jaar en belonen we nieuwe collega’s die in dienst komen in 2016 met een tekenbonus van maar liefst 3000 euro!) http://www.immune.it/nieuws/artikelen/tekenbonus-van-300000