Er zijn veel opties beschikbaar voor teams als het gaat om het schrijven en testen van software. Hoe bepaal je welke syntaxis je moet gebruiken en welke testoplossing het beste bij je past? In dit artikel gaan we in op het gebruik van Gherkin en Gherkin tests. We behandelen de syntaxis, hoe je een test schrijft en wat de voor- en nadelen zijn.
Deze opties kunnen onder de juiste omstandigheden een goede keuze zijn, maar er zijn bepaalde overwegingen die je in gedachten moet houden voordat je begint, vooral als je ook het testautomatiseringsproces meerekent.
Voordat we bespreken wat Gherkin is en hoe je Gherkin-tests schrijft, zijn er een paar dingen die we eerst moeten bespreken. Het is belangrijk om te begrijpen welke rol Behavior-Driven Development (BDD) speelt en hoe deze praktijk, Cucumber en Gherkin samenwerken.
Wat is BBD?
Behavior-Driven Development (BDD) is een ontwikkelmethode die de communicatie tussen teams bevordert. Deze gezamenlijke aanpak brengt de zakelijke en de technische aspecten van projecten samen. Deze methode stelt teams in staat om beter te communiceren over requirements, problemen vroegtijdig op te sporen en software gemakkelijk te onderhouden.
Teams die BBD gebruiken hebben een paar doelen. Het eerste doel is ervoor te zorgen dat de requirements door het hele team begrepen kunnen worden. Dan kunnen de teams zich concentreren op het voorkomen van mogelijke problemen, in plaats van op het blussen van brandjes als die later worden gevonden. Vaak betekent dit dat er minder her-werk nodig is.
Simpel gezegd kunnen we deze ontwikkeling in twee fasen beschrijven. Ontdekken en testen.
Eerst zoeken teams uit wat ze nog niet weten VOORDAT ze aan de slag gaan. Dan weten ze beter hoe ze op koers kunnen blijven en productiever kunnen zijn.
Wanneer het op testen aankomt, begint het proces van nadenken over deze testen al voordat de ontwikkeling begint. Tests worden geschreven om de implementatie en het eindproduct aan te sturen.
Wat is Cucumber?
Cucumber is een open-source software testing tool die BBD ondersteunt. (Behavior-Driven Development). Het werkt met Gherkin omdat de Gherkin syntax platte tekst zo structureert dat het door de tool kan worden gelezen.
Cucumber leest Gherkin tests en valideert dat de code presteert zoals het hoort. Het doet dit door Gherkin scenario’s en stappen te doorlopen. (Meer hierover hieronder). Cucumber zal dan een rapport maken dat laat zien of elke stap en scenario succesvol was of niet.
Wat is Gherkin?
Gherkin is een taal die ontwikkelaars gebruiken om tests in Cucumber te definiëren. Omdat deze taal gewoon Engels gebruikt, is het bedoeld om use-cases voor een softwaresysteem te beschrijven op een manier die door bijna iedereen kan worden gelezen en begrepen.
Deze syntaxis bevordert gedragsgestuurde ontwikkeling omdat het ontwikkelaars, managers, bedrijfsanalisten en andere betrokkenen in staat stelt om de vereisten van het project en de levenscyclus te begrijpen.
De taal maakt het gemakkelijk om eenvoudige documentatie te maken van de code die wordt geschreven. Gherkin biedt ook scripts voor testautomatisering en ondersteunt tientallen talen.
whitepaper
Gedragsgestuurde ontwikkeling. Wie heeft Gherkin nodig?
Hoe schrijf je Gherkin-tests
Om Gherkin-tests te schrijven, moet je eerst een aantal van de gebruikte trefwoorden begrijpen, en wat ze in de praktijk doen. Hier volgt een lijst met de meest gebruikte sleutelwoorden in de Gherkin syntax.
- Feature
- Regel
- Exemplaar
- Gegeven, Wanneer, Dan, En, Maar
- Achtergrond
- Scenario Outline
Elk sleutelwoord is essentieel voor het proces van het schrijven van een goede Gherkin test. Laten we eens wat dieper ingaan op deze sleutelwoorden en hoe je ze kunt gebruiken bij het schrijven van Gherkin tests.
Feature
Gherkin documenten beginnen met dit sleutelwoord, gevolgd door tekst die een beschrijving geeft. Eenvoudiger gezegd, de eigenschap is een beschrijving van wat de software verondersteld wordt te doen. Dit sleutelwoord wordt ook gebruikt om scenario’s te groeperen.
Dit is niet echt voor testdoeleinden, maar het stelt je in staat documentatie toe te voegen over eisen en bedrijfsregels. De beschrijvingssectie eindigt wanneer u een nieuwe regel begint met een van de andere trefwoorden, zoals scenario schets, voorbeeld of regel.
Beschrijvingen
Als het nodig is, kunnen ook vrije beschrijvingen worden geschreven onder de hierboven genoemde trefwoorden, zolang geen van uw regels begint met een trefwoord.
Regel
Het regel trefwoord wordt gebruikt om een bedrijfsregel weer te geven die moet worden opgenomen. Dit biedt context voor een functie. Deze “regels” moeten meer dan één scenario hebben om de regel te tonen en kunnen een achtergrondsectie hebben. (Gedetailleerd hieronder).
Gherkin Stappen
Naar aanleiding van dit artikel gaan we eens kijken naar enkele stappen in Gherkin tests. Dit zijn Given, When, Then, And, of But.
Given
Given stappen zetten de toon voor het scenario. In de meeste gevallen beschrijven deze stappen iets dat in het verleden heeft plaatsgevonden. Dit geeft het systeem context voordat een gebruiker ermee gaat interacteren. Om deze reden moet je in deze stap geen gebruikersinteracties behandelen. Denk na over wat je in deze stap opneemt als randvoorwaarden.
Note: Je kunt meer dan één Given stap hebben.
When
When stappen zijn actiestappen. Ze beschrijven een gebeurtenis. Voorbeelden zijn een gebeurtenis die wordt veroorzaakt door een ander systeem of door interactie van een gebruiker met het systeem. Het wordt aanbevolen om slechts één wanneer-stap te hebben voor elk scenario.
Then
Then-stappen zijn uitkomststappen. Hier beschrijf je wat je wilt dat het systeem doet, zodat het kan worden vergeleken met hoe de software in de praktijk presteert. Dit moet iets zijn dat je daadwerkelijk als resultaat kunt zien, zoals een bericht of een rapport.
En, maar
Wanneer je meerdere van een van de bovenstaande staptypen hebt, kun je en of maar gebruiken. Dit helpt om uw documentatie overzichtelijk en leesbaar te houden.
Achtergrond
Zoals hierboven vermeld, kunt u met de achtergrond nog meer context toevoegen aan de scenario’s in een functie. Dit is waar je meer dan één gegeven stap kunt hebben, als dat nodig is.
Note: Er kan maar één achtergrondstap zijn voor elke functie. Als je meer achtergrondstappen nodig hebt, zul je verschillende feature files moeten maken.
Scenario Outline
De scenario outline bevat een voorbeelden sectie. Deze stappen worden gelezen als een sjabloon. De scenario outline loopt eenmaal voor elke rij van de voorbeeld sectie, behalve voor de header rij.
Pros and Cons of Using Gherkin
Nu je weet hoe je een Gherkin test moet schrijven, vraag je je misschien af hoe je kunt bepalen of dit de juiste optie is voor jouw team. Er zijn zowel voor- als nadelen verbonden aan het gebruik van Gherkin en Cucumber. Laten we er een paar nader bekijken.
Gherkin is eenvoudig
In de kern is Gherkin eenvoudig te begrijpen voor zowel ontwikkelaars als leidinggevenden. In zekere zin is het “niet-technisch”, waardoor samenwerking tussen teams eenvoudiger wordt.
Gericht op projecteisen
De syntaxis van Gherkin en dit type testen zijn echt gericht op het project en de zakelijke eisen. Dit zorgt voor een ontwikkelingsproces dat is gebouwd met de gebruikerservaring in gedachten.
Hergebruik van code
De manier waarop deze tests zijn geschreven maakt het makkelijker om delen van de code van andere tests te hergebruiken. Dit kan oplopen en bespaart tijd, geld en resources.
Niet voor alle projecten
Gherkin + Cucumber is niet ideaal voor alle projecttypes. Korte projecten die veel getest moeten worden, kunnen met deze methode vertraging oplopen. Hoewel BBD een tijd en plaats heeft, kan deze manier van denken en de implementatie van deze tests projecten vertragen.
Het vereist veel betrokkenheid
Dit kan een voor- of een nadeel zijn, afhankelijk van de ontwikkelmethodologie van uw team. Zoals eerder gezegd, gaan Gherkin en Cucumber hand in hand met gedragsgestuurde ontwikkeling. Dit betekent dat je team constant moet samenwerken, wat misschien niet altijd bij je project past.
Mogelijke kosten
Hoewel deze tests makkelijker te schrijven zijn, kan een slecht geschreven test resulteren in veel extra tijd en geldverspilling als tests opnieuw geschreven moeten worden. Tenzij ontwikkelaars Gherkin en Cucumber goed begrijpen, kan dit soort testen een enorm financieel risico vormen
De toekomst van Gherkin
Hier bij Functionize geloven we dat het afstappen van Gherkin de toekomst is en betere voordelen zal opleveren. Gherkin is één manier waarop mensen testplannen uitschrijven, maar daar houdt het proces niet op. Ontwikkelaars moeten nog steeds testscripts uitschrijven. Dit proces kan veel tijd kosten die ontwikkelaars elders zouden kunnen besteden.
Gherkin is een goede eerste stap om niet-technische mensen bij automatiseringstesten te betrekken. Maar onze klanten wenden zich tot onze ALP omdat wij ‘de tussenpersoon uit de weg ruimen’ die Selenium moet scripten en het maken van tests eenvoudig maken.
Wrapping Up
Gherkin en Cucumber kunnen een goede keuze zijn wanneer iedereen in het team op de hoogte moet zijn zonder zich in technische aspecten te hoeven verdiepen. Deze combinatie kan testautomatisering echter ingewikkelder maken dan nodig is.
De keuze is aan jou, maar voordat je een syntax en oplossing kiest, moet je de voors en tegens zorgvuldig overwegen. Het belangrijkste is dat u en uw team de juiste tools krijgen voor uw ontwikkelprojecten.
Hoewel, onze mening is dat Gherkin simpelweg te inflexibel is en moeilijk te leren. Onze oplossing is onze onlangs uitgebrachte Adaptive Language Processing engine (ALP™). Hiermee kunt u tests schrijven als een reeks stappen in gewoon Engels.
Deze blog ging in op wat Gherkin testen is, hoe u Gherkin tests schrijft en de voor- en nadelen van het gebruik van deze syntaxis. We hopen dat dit u inzicht heeft gegeven in de beste taal en testopties voor uw volgende project.