Ga naar hoofdinhoud

Gherkin

Inleiding​

Vertaald uit: GherkinUFT.com (n.d.). Gherkin's Golden Rule

Gherkin vs Cucumber

Over deze uitklapbalk komen geen toetsvragen, maar het is wel handig om wat namen te kennen voor als je praat met collega's. En grappig dat er ook een Nederlandse achtergrond is.

Gherkin Logo Gherkin*

De specificatie taal met feature en given, when en then (of vertalingen hiervan in andere talen) heet Gherkin.

"The name “gherkin” comes from the Dutch word “gurken,” which means small pickled cucumber." - Masterclass.com, 2021

* Gherkin heeft geen eigen logo, en je vindt online meestal het Cucumber logo erbij, dat helpt niet om het onderscheid te maken. Maar Siyahov (2023) maakte dit plaatje.

Cucumber Logo Cucumber

Het (test) framework voor Java heet Cucumber. Hiermee maak je glue code, om je features echt te koppelen aan je uitvoerbare tests via Java annotaties als @Given(...) etc. Maar Voor andere talen zijn er vergelijkbare frameworks zoals SpecFlow voor C#/.NET en Behave voor Python. Maar de specificatietaal heet dus altijd Gherkin. Deze bestanden moeten ook voor business analisten en product owners leesbaar zijn, en zijn dus gewoon in 'natuurlijk taal'. Wel stel je ze als developer vaak alsnog op, omdat het best algoritmisch van aard wordt, zeker bij grote testsuites. Je wilt je specificaties dan ook DRY houden.

"The Gherkin syntax is named after the small pickled cucumber, which is a reference to the idea of "pickling" or preserving the requirements of a user story in a structured, easy-to-understand format. The name was chosen to reflect the simplicity and ease of use of the syntax." - RedRockResearch.com, 2023

Waarom Gherkin?​

Omdat Cucumber...

Man shrug.

En waarom Cucumber? Omdat:

"Aslak Hellesøy creator of Cucumber was working on extensions/hack of BDD tools and had initially named the whole thing as “Stories”. Then one day on a 3-hour bus journey with his fiancee Patty, he did check with her for a catchy,non-geeky sounding name for the tool he was developing and Patty out of no where said “Cucumber” and the creator thought that looks cool and thought he can rename again if he finds something more interesting and rest is history." — https://cognideep.medium.com/cucumber-65d81ce4193a

Man shrug.

Het schrijven van goede Gherkin begint met deze uitgangspunten:

  • Behandel andere lezers zoals je zelf behandeld wilt worden
  • Meer specifiek, schrijf functiebestanden op zo'n manier dat iedereen ze intuïtief kan begrijpen
  • Goede Gherkin zou de samenwerking in teams moeten verbeteren door duidelijk te maken welk gedrag je wilt ontwikkelen
  • Als Gherkin moeilijk te lezen is voor anderen, kunnen teamleden ook geen goed gedrag ontwikkelen

Hier een voorbeeld van een goed scenario:

Scenario: Toevoegen van schoenen aan een winkelwagen
  Gegeven een online schoenenwinkel
  Wanneer de klant zoekt naar "rode hakschoenen"
  En de klant voegt het eerste resultaat toe aan zijn winkelwagen
  Dan bevat de winkelwagen een paar "rode hakschoenen"

Dit scenario heeft declaratieve, beschrijvende stappen. De stappen volgen een strict gegeven-wanneer-dan volgorde die duidelijk de opzet, interactie en verificatie van gewenst gedrag weergeven. Het scenario gebruikt "rode hakschoenen" als concreet voorbeeld om de lezer het scenario beter te helpen begrijpen. Het scenario is beknopt en toch ondubbelzinnig. Ook al bevat het geen enkele user interface details.

Grammatica​

Vertaald uit: GherkinUFT.com (n.d.). The good grammar rule

  • Taal is belangrijk, dus schrijf alsof je taal leraar (Nederlands of Engels) van de middelbare school je Gherkin zal beoordelen.
  • Gedragsscenario's moeten leesbaar en expressief zijn.
  • Stappen moeten herbruikbaar zijn.
  • Slechte grammatica, spelfouten en inconsistente formuleringen kunnen de voordelen van gedragsspecificaties te niet doen. Scenario's kunnen verwarrend worden en teamleden kunnen stappen buiten hun context gebruiken.

Een van de meest gemaakte taalproblemen met Gherkin is het schrijven vanuit een inconsistent gezichtspunt. Je kunt stappen schrijven vanuit eerste-persoonsperspectief ("ik, mij, mijn") of vanuit derde-persoonsperspectief ("de gebruiker ..."). Hoewel we een sterke voorkeur heb voor het derde-persoonsperspectief voor stappen in Gherkin, is het voor een oplossing het belangrijkste om uitsluitend het ene of het andere te gebruiken.

Een ander probleem dat vaak voorkomt heeft te maken met de tijd: verleden, heden en toekomst. Elk type stap moet consistente regels volgen binnen een oplossing. Ik raad het volgende aan:

  • 'Gegeven' stappen moeten verleden of tegenwoordige tijd gebruiken, omdat ze een begintoestand vertegenwoordigen die al moet zijn vastgesteld.
  • 'Wanneer' stappen moeten de tegenwoordige tijd gebruiken, omdat ze acties weergeven die actief worden uitgevoerd als onderdeel van het gedrag.
  • 'Dan' moeten stappen de tegenwoordige of toekomende tijd gebruiken, omdat ze weergeven wat er moet gebeuren na de gedragsacties.
Achtergrond:
  #Feiten
  Gegeven het volgende vluchtschema:
    | Van     | Naar      | Klas      | Punten  |
    | Londen  | New York  | Budget    | 550     |
    | Londen  | New York  | Zakelijk  | 800     |
  En Stacey is lid van de club van frequente vliegers

Scenario: Vluchten leveren punten op basis van afgelegde afstand en cabine klasse op

  #Verleden tijd
  Gegeven Stacey die deze tickets heeft gekocht:
    | Van       | Naar      | Klas      |
    | Londen    | New York  | Budget    |
    | New York  | Londen    | Zakelijk  |
  #Tegenwoordige tijd
  Wanneer ze de vluchten heeft genomen
  #Toekomende tijd (of "zou moeten")
  Dan verdient ze 1350 punten

Declaratief vs Imperatief​

Vertaald uit: Smart J.F. (2022). BDD scenario, imperative or declarative?

Moeten Gherkin-scenario's imperatief of declaratief zijn?

Het is een beetje een "no-brainer".

Imperatieve scenario's geven de illusie van dekking, maar in feite dekken ze slechts een klein stukje gebruikersgedrag. Bovendien proberen ze meestal veel dingen te testen, waardoor ze verwarrend en moeilijk leesbaar zijn.

❌ Imperatieve scenario's zijn meestal nauw gekoppeld aan de implementatie (UI of API), wat betekent dat als de implementatie verandert, de scenario's ook moeten veranderen.

Declaratieve scenario's leggen de intentie en de regels vast, inclusief voorbeelden en tegenvoorbeelden op meerdere niveaus. Dit maakt het veel gemakkelijker om een hoge dekking te krijgen en een duidelijker beeld van wat de business eigenlijk nodig heeft.

Declaratieve scenario's verbergen implementatiedetails onder de motorkap, in herbruikbare codecomponenten die gemakkelijker te onderhouden zijn, wat leidt tot stabielere, betrouwbare testsuites. De scenario's hoeven alleen te worden aangepast als de bedrijfslogica verandert.

Een mooi voorbeeld: BDD scenario met en zonder UI details

Basis regels voor een BDD-scenario​

Vertaald uit: Smart J.F. (2022). BDD scenario should have a single reason to change

De belangrijkste basisregel van een BDD-scenario is een één-op-één regel (DRY, SRP, etc.):

Eén scenario moet precies één enkel, onafhankelijk gedrag behandelen.

Focussen op één gedrag heeft verschillende voordelen:

  • Samenwerking: Meer focus en minder verwarring
  • Automatisering: Elke testfout wijst op een uniek probleem
  • Efficiëntie: Minder complex werk zorgt voor snellere cyclustijden
  • Traceerbaarheid: 1 gedrag → 1 voorbeeld → 1 scenario → 1 test → 1 resultaat
  • Verantwoording: Teams kunnen gedrag niet verbergen of vermijden
gevaar

Wanneer een scenario meer dan één wanneer-dan paar heeft, omvat het inherent al meer dan één gedraging.

Keep the UI out​

Vertaald uit: Smart J.F. (2022). BDD scenario focused on business flows, business rules and business value

Een BDD-scenario zou slechts één reden moeten hebben om te veranderen en die reden zou moeten zijn dat de business rule verandert.

Kortom je moet de onderliggende UI of API's er volledig uit kunnen trekken en herschrijven: wanneer de bedrijfslogica niet verandert, dan moet dat ook niet gelden voor je BDD-scenario's.

De truc om dit te bereiken is om je te richten op het modelleren van gedrag en niet op de implementatie. Beschrijf zakelijke taken en doelen, geen knoppen en klikken.

De vuistregel is dat je als lezer van een scenario niet zou moeten weten hoe dit geautomatiseerd kan worden. Focus op de wat van het probleem en niet de hoe dit te op te lossen.

Kortom je zou de UI volledig moeten kunnen veranderen en toch je BDD-scenario's kunnen behouden, omdat de BDD-scenario's de bedrijfsregels en vereisten vastleggen, NIET de implementatie.

Gebruik echte problemen uit het domein​

Vertaald uit: Smart J.F. (2022). BDD scenario talks about real-world problems

Goede BDD-scenario's gaan over echte problemen, natuurlijk geschreven in de taal van het domein. Onderstaand voorbeeld komt uit de luchtvaartindustrie.

Voorbeeld BDD scenario voor een vliegtuig

Figuur: Voorbeeld BDD scenario voor een vliegtuig

  • Merk ook op hoe er geen klikken, geen knoppen, geen implementatiedetails zijn: gewoon 100% puur zakelijke vereisten.

Gebruik concrete voorbeelden​

Vertaald uit: Smart J.F. (2022). BDD scenario using concrete examples

Het belangrijkste idee van gherkin is dan ook om CONCRETE VOORBEELDEN van gebruikersgedrag en bedrijfsregels te gebruiken. Als output van het voeren van gestructureerde gesprekken met mensen uit het bedrijfsleven en teamleden om deze voorbeelden te ontdekken en uit te werken. We kunnen deze in een formaat als Gherkin schrijven zodat ze geautomatiseerd kunnen worden en zowel snellere feedback als geautomatiseerde acceptatie-/regressietests opleveren.

Hier zijn nog een paar tips:

  • 👉 Begin altijd met het gesprek, begin nooit met Gegeven..Wanneer..Dan....
  • 👉 Focus op het beschrijven van het probleem, niet op de oplossing
  • 👉 Vind je Gherkin Dialect, dat begrijpelijk EN betekenisvol is voor het hele team.

Het unieke voorbeeld​

Vertaald uit: GherkinUFT.com (n.d.). The unique example rule

Soms is minder meer ("less is more"), dus voeg ook geen onnodige voorbeelden toe. Richt je in plaats daarvan op unieke gelijkwaardigheid klassen. Het klinkt misschien verleidelijk om "alle dingen" te testen, maar daarmee verspil je kostbare tijd. Test in plaats daarvan de belangrijkste dingen en vermijd het testen van dubbele dingen.

Te eenvoudige scenario's?​

Vertaald uit: Smart J.F. (2022). BDD scenario, can a scenario be too simple?

Gherkin moet zo eenvoudig zijn als nodig, maar niet eenvoudiger. We weten nu dat Gherkin scenario's het bedrijfsprobleem dat opgelost moet worden op een heldere en eenvoudige manier moet beschrijven. Maar Gherkin scenario's kunnen soms TE eenvoudig zijn. Ze richten zich op triviale voorbeelden, of stellen simpelweg het voor de hand liggende (zoals in Voorbeeld 1). Niemand leert veel van het lezen van de Gherkin scenario's. Niemand leert van het lezen of bespreken ervan.

In andere gevallen verwijzen ze gewoon naar een voorbeeld dat de gebruiker of BA (business analist) geeft, maar zonder de probleemruimte te ontwikkelen of te verkennen. Dit geeft een te vereenvoudigd beeld van het probleem, waarbij belangrijke randgevallen en aannames ontbreken, en kan leiden tot broze of moeilijk te automatiseren scenario's (zoals in Voorbeeld 2).

Goede Gherkin scenario's leggen niet alleen vast wat de gebruiker vraagt; ze verkennen het onderliggende bedrijfsprobleem. Ze leggen niet de initiële vraag van de gebruiker vast, maar de uitkomsten (in de vorm van bedrijfsregels en voorbeelden) van het gesprek dat het team heeft met de stakeholders.

En dat maakt het verschil.

Samenvatting van eisen aan goede Gherkin​

Scenario​

  • Een scenario moet precies één enkel, onafhankelijk gedrag behandelen.
  • Een scenario heeft een betekenisvolle actor
  • Een scenario is gebaseerd op een concreet voorbeeld
  • Een scenario bevat geen UI details
  • Soms is minder meer, dus voeg geen onnodige voorbeelden toe of voorbeelden die te eenvoudig zijn
  • Een scenario is beknopt en ondubbelzinnig dus zonder slechte grammatica, spelfouten en inconsistente formuleringen

Stappen​

  • Een scenario bestaat uit drie stappen die een strict gegeven-wanneer-dan volgorde volgen
    • Gegeven stap moet geschreven zijn in de verleden, voltooide of tegenwoordige tijd
    • Wanneer stap moet geschreven zijn in de tegenwoordige tijd
    • Dan stap moet geschreven zijn in de tegenwoordige of toekomende tijd
  • Stappen beschrijven één ding, bij gecombineerde dingen gebruik je een voegwoord
    • En of Maar zijn voegwoorden die gebruikt kunnen worden om een scenario stap op te delen
  • Stappen zijn declaratief en beschrijvend
    • Voorkeur voor het derde-persoonsperspectief bij het beschrijven van de stappen in Gherkin
  • Stappen maken voor zover mogelijk gebruik van de terminologie uit het domein
    • taalgebruik moet zo goed mogelijk overeenkomen met andere bronnen die het domein beschrijven

Bronnen​