Implementera Cucumber-scenariomallar i beteendedrivna utvecklingsramverk
Beteendedriven utveckling (BDD) är en agil programvaruutvecklingsmetod som förbättrar samarbetet mellan intressenter och utvecklare genom att använda ett enkelt, domänspecifikt språk för att beskriva systembeteende.
Ett av de mest kraftfulla verktygen inom BDD är Cucumber, som används för att skriva tydliga specifikationer. Det kan också användas för testning med de vanligaste programmeringsspråken, till exempel Java, Python eller C#, och kan integreras med användargränssnittsramverk som Selenium eller användas för API-testning.
Scenariomallar är en del av Cucumber-syntaxen Gherkin och används för att skriva körbara specifikationer. Till skillnad från vanliga scenarier, som definierar ett enda konkret exempel, gör scenariomallar det möjligt att specificera flera exempel i tabellformat.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Skillnader mellan scenarier och scenariomallar
Scenarier i Cucumber representerar ett testfall skrivet i den grundläggande formen givet-när-sedan. Med språket Gherkin kan dessa testscenarier skrivas på vanlig engelska (och andra språk), så att de enkelt kan förstås och även skrivas av personer utan teknisk bakgrund. Stegdefinitionerna, som representerar implementeringen av stegen, skapas i separata filer.
För vissa funktioner är det meningsfullt att upprepa samma scenario med olika testdata – du känner förmodligen igen detta som datadriven testning. I Cucumber görs detta genom att använda en scenariomall med en exempeltabell som innehåller de datauppsättningar som ska användas. Varje exempel räknas som ett separat test.
Syntax för Cucumber-scenariomallar
Det typiska Cucumber-projektet innehåller funktionsfiler, där Cucumber-testerna definieras, och stegdefinitionsfiler med implementeringarna av stegen.
En funktionsfil bör representera en kravspecifikation och de scenarier som används för att testa den. Den grundläggande syntaxen för ett enkelt Cucumber-scenario ser ut så här:
Scenario: Ogiltig inloggning
Givet att jag navigerar till inloggningssidan
När jag anger ogiltiga inloggningsuppgifter
Sedan får jag ett felmeddelande
Scenariot kan också innehålla variabler, som kommer att behandlas som sådana i stegdefinitionen.
Scenario: Ogiltig inloggning
Givet att jag navigerar till inloggningssidan
När jag anger användarnamnet test och det ogiltiga lösenordet
Sedan får jag ett felmeddelande: "Ogiltig inloggning".
Värdena “test”, “ogiltig” och “Ogiltig inloggning” kommer att behandlas som variabler. Låt oss nu se vad som händer när vi vill prova olika kombinationer av de angivna variablerna – vi kan sluta med flera scenarier som är identiska bortsett från variabelvärdena, eller använda scenariomallen, som gör det möjligt för oss att använda en tabell där vi definierar de olika datakombinationerna:
Sedan får jag ett felmeddelande: "<felmeddelande>".
Exempel:
| användarnamn | lösenord | felmeddelande |
| test | ogiltigt | Ogiltig inloggning |
| test | | Ange lösenordet |
| | ogiltigt | Ange användarnamnet |
Kombinationen av data skrivs under nyckelordet “Exempel”, inuti en tabell. Tabellernas rubriker är variabelnamnen och varje rad representerar en datakombination. Varje exempel i en Cucumber-funktionsfil kommer att behandlas som ett individuellt testfall.
Exempeltabeller jämfört med datatabeller
Exempel- och datatabeller kan se likadana ut, men de har olika syften. Den huvudsakliga skillnaden är att exempel används för att implementera datadrivna scenarier, medan datatabeller används när scenariostegen behöver använda flera variabler.
En datatabell kan användas så här:
Scenario: Ogiltig inloggning
Givet att jag navigerar till inloggningssidan
När jag anger inloggningsuppgifterna
| användarnamn | lösenord |
| test | ogiltigt |
Sedan får jag ett felmeddelande: "Ogiltig inloggning".
eller så här:
Scenario: Ogiltig inloggning
Givet att jag navigerar till inloggningssidan
När jag anger autentiseringsuppgifterna
| användarnamn | test |
| lösenord | ogiltigt |
Då får jag ett felmeddelande: "Ogiltig inloggning".
Datatabeller är särskilt användbara när stegen kräver flera variabler, och de är lättare att läsa än när varje värde skrivs inuti steget.
Arbeta med datatabeller och scenarioöversikter
Datatabeller och scenarioöversikter kan också fungera tillsammans. Variabelns namn anges i datatabellen och återanvänds sedan i exempeltabellen.
Scenarioöversikt: Ogiltig inloggning
Givet att jag navigerar till inloggningssidan
När jag anger autentiseringsuppgifterna
| användarnamn | <användarnamn> |
| lösenord | <lösenord> |
Då får jag ett felmeddelande: "<felmeddelande>".
Exempel:
| användarnamn | lösenord | felmeddelande |
| test | ogiltigt | Ogiltig inloggning |
| test | | Ange lösenordet |
| | ogiltigt | Ange användarnamnet |
Fördelar med att använda scenarioöversikter
Scenarioöversikter kan tolkas som en ”mall” för ett testfall. När de väl har implementerats i ett ramverk för testautomatisering utför de samma scenario med olika uppsättningar data.
Fördelen är att det blir färre rader Gherkin och mindre upprepning. Det innebär att när en ändring behövs i det gemensamma scenariot behöver den bara göras en gång, och ändringen tillämpas på alla kombinationer av testdata.
En annan fördel med scenarioöversikter är att de kan ge ökad täckning med minimalt arbete. Om du vill lägga till ett nytt test behöver du lägga till en ny exempelrad.
Bästa praxis för att skriva scenarioöversikter
- Inkludera verkliga data: Teamet är mindre benäget att förbise gränsfall eller dold information när det använder verkliga användningsfall för att förstå beteendet.
- Kommunicera målet med hjälp av affärsterminologi för att hjälpa teamets icke-tekniska och tekniska intressenter att förstå varandra bättre.
- Förklara din avsikt i stället för hur den ska implementeras; stegbeskrivningarna bör vara så lite tekniska som möjligt. De bör fokusera mer på systemets funktioner än på hur det fungerar
- Behåll bara det som är nödvändigt: För att hålla scenariot engagerande för alla deltagare bör du inte överbelasta det med onödiga steg.
Sammanfattning
Förbättrat samarbete: Beteendedriven utveckling förbättrar samarbetet mellan intressenter och utvecklare.
Enkelt språk: Beteendedriven utveckling använder ett enkelt, domänspecifikt språk för att beskriva systemets beteende.
Agilt arbetssätt: Beteendedriven utveckling är ett arbetssätt inom agil programvaruutveckling.
Intressenternas medverkan: Beteendedriven utveckling involverar intressenter i definitionen av systemets beteende.
Beskrivning av systemets beteende: Beteendedriven utveckling fokuserar på att effektivt beskriva systemets beteende.
Cucumber är ett utmärkt samarbetsverktyg för icke-tekniska personer, utvecklare och testare. Det är ett BDD-verktyg som tillhandahåller skriftliga specifikationer och kan användas vid testning. Flera scenarier kan skrivas för att demonstrera olika krav.
Det är en god idé att använda en scenarioöversikt med särskilda uppsättningar värden som anges i exempeltabellen när scenarierna har samma steg men kräver olika datavärden som indata eller utdata.
Prenumerera på The CTO Clubs nyhetsbrev för fler insikter.
