Scenario-overzichten implementeren in BDD-frameworks
Behavior-driven development (BDD) is een agile softwareontwikkelingspraktijk die de samenwerking tussen belanghebbenden en ontwikkelaars verbetert door eenvoudige, domeinspecifieke taal te gebruiken om het gedrag van systemen te beschrijven.
Een van de krachtigste tools in BDD is Cucumber, dat wordt gebruikt om duidelijke specificaties te schrijven. Het kan ook worden gebruikt voor tests, met de meest gebruikte programmeertalen, zoals Java, Python of C#, en kan worden geïntegreerd met UI-frameworks, zoals Selenium, of worden gebruikt voor API-tests.
Scenario-overzichten maken deel uit van de Gherkin-syntaxis van Cucumber, die wordt gebruikt om uitvoerbare specificaties te schrijven. In tegenstelling tot reguliere scenario's die één concreet voorbeeld definiëren, maken scenario-overzichten het mogelijk om meerdere voorbeelden in tabelvorm te specificeren.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Verschillen tussen scenario's en scenario-overzichten
Scenario's in Cucumber vertegenwoordigen een testcase die is geschreven in de basisvorm van gegeven-wanneer-dan. Met de Gherkin-taal kunnen deze testscenario's in eenvoudig Nederlands (en andere talen) worden geschreven, zodat ze gemakkelijk kunnen worden begrepen en zelfs door niet-technische mensen kunnen worden geschreven. De stapdefinities, die de implementatie van de stappen vertegenwoordigen, worden in afzonderlijke bestanden aangemaakt.
Voor sommige functionaliteiten is het zinvol om hetzelfde scenario te herhalen met verschillende testgegevens - dit staat waarschijnlijk bekend als datagestuurd testen. In Cucumber gebeurt dit door het scenario-overzicht te gebruiken met een tabel met voorbeelden die de te gebruiken gegevenssets bevat. Elk voorbeeld wordt als een afzonderlijke test geteld.
Syntaxis van een Cucumber-scenario-overzicht
Een typisch Cucumber-project bevat featurebestanden, waarin de Cucumber-tests worden gedefinieerd, en stapdefinitiebestanden, met de implementaties van de stappen.
Een featurebestand moet een requirementspecificatie en de scenario's waarmee deze wordt getest vertegenwoordigen. De basissyntaxis voor een eenvoudig Cucumber-scenario is als volgt:
Scenario: Ongeldige login
Gegeven dat ik naar de inlogpagina ga
Wanneer ik ongeldige inloggegevens invoer
Dan ontvang ik een foutmelding
Het scenario kan ook variabelen bevatten, die als zodanig in de stapdefinitie worden behandeld.
Scenario: Ongeldige login
Gegeven dat ik naar de inlogpagina ga
Wanneer ik gebruikersnaam test en ongeldig wachtwoord invoer
Dan ontvang ik een foutmelding: "Ongeldige login".
De waarden “test”, “ongeldig” en “Ongeldige login” worden als variabelen behandeld. Laten we nu bekijken wat er gebeurt wanneer we verschillende combinaties van de opgegeven variabelen willen uitproberen - we zouden kunnen eindigen met meerdere scenario's die identiek zijn, op de variabele waarden na, of het scenario-overzicht gebruiken, waarmee we een tabel kunnen gebruiken waarin we de verschillende gegevenscombinaties definiëren:
Dan ontvang ik een foutmelding: "<foutmelding>".
Voorbeelden:
| gebruikersnaam | wachtwoord | foutmelding |
| test | ongeldig | Ongeldige login |
| test | | Voer het wachtwoord in |
| | ongeldig | Voer de gebruikersnaam in |
De gegevenscombinatie wordt onder het trefwoord “Voorbeelden” in een tabel geschreven. De kopteksten van de tabellen zijn de variabelenamen; vervolgens vertegenwoordigt elke rij de gegevenscombinatie. Elk voorbeeld in een Cucumber-feature wordt behandeld als een afzonderlijke testcase.
Tabel met voorbeelden versus gegevenstabellen
De tabellen met voorbeelden en gegevenstabellen lijken misschien op elkaar, maar ze dienen verschillende doelen. Het belangrijkste verschil is dat tabellen met voorbeelden worden gebruikt om datagestuurde scenario's te implementeren, terwijl gegevenstabellen worden gebruikt wanneer de scenariostappen meerdere variabelen moeten gebruiken.
Een gegevenstabel kan er als volgt uitzien:
Scenario: Ongeldige login
Gegeven dat ik naar de inlogpagina ga
Wanneer ik de inloggegevens invoer
| gebruikersnaam | wachtwoord |
| test | ongeldig |
Dan ontvang ik een foutmelding: "Ongeldige login".
of zo:
Scenario: Ongeldige login
Gegeven dat ik naar de loginpagina navigeer
Wanneer ik de inloggegevens invoer
| gebruikersnaam | test |
| wachtwoord | ongeldig |
Dan ontvang ik een foutmelding: "Ongeldige login".
Gegevenstabellen zijn vooral nuttig wanneer de stappen meerdere variabelen vereisen en ze zijn gemakkelijker te lezen dan wanneer elke waarde in de stap wordt geschreven.
Werken met gegevenstabellen en scenario-overzichten
Gegevenstabellen en scenario-overzichten kunnen ook samenwerken. De naam van de variabele wordt in de gegevenstabel opgegeven en vervolgens opnieuw gebruikt in de tabel met voorbeelden.
Scenario-overzicht: Ongeldige login
Gegeven dat ik naar de loginpagina navigeer
Wanneer ik de inloggegevens invoer
| gebruikersnaam | <gebruikersnaam> |
| wachtwoord | <wachtwoord> |
Dan ontvang ik een foutmelding: "<foutmelding>".
Voorbeelden:
| gebruikersnaam | wachtwoord | foutmelding |
| test | ongeldig | Ongeldige login |
| test | | Voer het wachtwoord in |
| | ongeldig | Voer de gebruikersnaam in |
Voordelen van het gebruik van scenario-overzichten
Scenario-overzichten kunnen worden geïnterpreteerd als een “sjabloon” van een testcase. Wat ze daadwerkelijk doen wanneer ze in een testautomatiseringsraamwerk zijn geïmplementeerd, is hetzelfde scenario uitvoeren met verschillende gegevenssets.
Het voordeel is dat er minder regels Gherkin en minder herhaling zijn. Dit betekent dat wanneer er een wijziging nodig is in het gemeenschappelijke scenario, deze slechts één keer hoeft te worden aangebracht en de wijziging op alle combinaties van testgegevens wordt toegepast.
Een ander voordeel van scenario-overzichten is dat ze met minimale inspanning een grotere dekking kunnen bieden. Om een nieuwe test toe te voegen, moet je een nieuwe regel met een voorbeeld toevoegen.
Beste praktijken voor het schrijven van scenario-overzichten
- Gebruik echte gegevens: Het team zal minder snel randgevallen of verborgen informatie over het hoofd zien wanneer het realistische gebruikssituaties toepast om gedrag te begrijpen.
- Communiceer het doel met behulp van bedrijfsterminologie, zodat de niet-technische en technische belanghebbenden van het team elkaar beter begrijpen.
- Leg je bedoeling uit in plaats van hoe deze wordt geïmplementeerd; de uitleg van de stappen moet zo min mogelijk technisch zijn. Deze moet meer gericht zijn op de functies van het systeem dan op de werking ervan.
- Beperk je tot wat nodig is: Om het scenario boeiend te houden voor alle deelnemers, moet je het niet overladen met onnodige stappen.
Belangrijkste punten
Samenwerking verbeteren: BDD verbetert de samenwerking tussen belanghebbenden en ontwikkelaars.
Eenvoudige taal: BDD gebruikt een eenvoudige, domeinspecifieke taal om het gedrag van systemen te beschrijven.
Agile-praktijk: BDD is een praktijk binnen agile softwareontwikkeling.
Betrokkenheid van belanghebbenden: BDD betrekt belanghebbenden bij het definiëren van systeemgedrag.
Beschrijving van systeemgedrag: BDD richt zich op het effectief beschrijven van systeemgedrag.
Cucumber is een geweldig samenwerkingshulpmiddel voor niet-technische mensen, ontwikkelaars en testers. Het is een BDD-hulpmiddel dat schriftelijke specificaties biedt en kan worden gebruikt bij het testen. Er kunnen meerdere scenario's worden geschreven om verschillende vereisten te demonstreren.
Het is een goed idee om een scenario-overzicht te gebruiken met afzonderlijke waardensets die via de tabel met voorbeelden worden opgegeven wanneer scenario's dezelfde stappen hebben, maar verschillende gegevenswaarden als invoer of uitvoer vereisen.
Abonneer je op de nieuwsbrief van The CTO Club voor meer inzichten.
