Implementering av Cucumber-scenarioomriss i BDD-rammeverk

Atferdsdrevet utvikling (BDD) er en smidig praksis for programvareutvikling som forbedrer samarbeidet mellom interessenter og utviklere ved å bruke et enkelt, domenespesifikt språk til å beskrive systematferd. 

Et av de mest kraftige verktøyene i BDD er Cucumber, som brukes til å skrive tydelige spesifikasjoner. Det kan også brukes i testing med de mest brukte programmeringsspråkene, som Java, Python eller C#, og kan integreres med brukergrensesnittsrammeverk som Selenium eller brukes til API-testing.

Scenarioomriss er en del av Cucumber-syntaksen Gherkin, som brukes til å skrive kjørbare spesifikasjoner. I motsetning til vanlige scenarier, som definerer ett enkelt konkret eksempel, gjør scenarioomriss det mulig å spesifisere flere eksempler i tabellformat. 

Forskjeller mellom scenarier og scenarioomriss

Scenarier i Cucumber representerer et testtilfelle skrevet i grunnformen gitt–når–så. Gherkin-språket gjør det mulig å skrive disse testscenarioene på vanlig engelsk (og andre språk), slik at de enkelt kan forstås og til og med skrives av ikke-tekniske personer. Stegdefinisjonene, som representerer implementeringen av stegene, opprettes i separate filer. 

For enkelte funksjoner er det hensiktsmessig å gjenta det samme scenarioet med ulike testdata – du kjenner kanskje dette som datadrevet testing. I Cucumber gjøres dette ved å bruke scenarioomrisset sammen med en eksempeltabell som inneholder datasettene som skal brukes. Hvert eksempel telles som en separat test.  

Syntaks for scenarioomriss i Cucumber

Et typisk Cucumber-prosjekt inneholder funksjonsfiler, der Cucumber-testene er definert, og stegdefinisjonsfiler med implementasjonene av stegene. 

En funksjonsfil bør representere en kravspesifikasjon og scenariene som brukes til å teste den. Grunnsyntaksen for et enkelt Cucumber-scenario er slik:

Scenarioet kan også inneholde variabler, som vil bli behandlet som dette i stegdefinisjonen.

Verdiene «test», «ugyldig» og «Ugyldig innlogging» vil bli behandlet som variabler. La oss nå se hva som skjer når vi vil prøve ulike kombinasjoner av de oppgitte variablene – vi kan ende opp med flere scenarier som er identiske bortsett fra variabelverdiene, eller bruke scenarioomrisset, som gjør det mulig å bruke en tabell der vi definerer de ulike datakombinasjonene:

Kombinasjonen av data skrives under nøkkelordet «Eksempler», inne i en tabell. Tabellens overskrifter er variabelnavnene, og hver rad representerer en kombinasjon av data. Hvert eksempel i en Cucumber-funksjon vil bli behandlet som et individuelt testtilfelle. 

Eksempeltabeller kontra datatabeller

Eksempel- og datatabeller kan se like ut, men de har ulike formål. Hovedforskjellen er at eksempler brukes til å implementere datadrevne scenarier, mens datatabeller brukes når scenariostegene må benytte flere variabler.

En datatabell kan brukes slik:

eller slik:

Datatabeller er spesielt nyttige når trinnene krever flere variabler, og de er enklere å lese enn når hver verdi skrives inn i trinnet.  

Arbeide med datatabeller og scenarioomriss 

Datatabeller og scenarioomriss kan også fungere sammen. Navnet på variabelen angis i datatabellen og brukes deretter på nytt i eksempeltabellen.

Fordeler ved å bruke scenarioomriss

Scenarioomriss kan tolkes som en «mal» for en testtilfelle. Det de egentlig gjør når de er implementert i et testautomatiseringsrammeverk, er å kjøre det samme scenarioet med ulike datasett.

Fordelen er at det blir færre Gherkin-linjer og mindre gjentakelse. Dette betyr at hver endring som trengs i det felles scenarioet, bare trenger å gjøres én gang, og endringen vil bli brukt på alle kombinasjoner av testdata.

En annen fordel med scenarioomriss er at de kan gi økt dekning med minimal innsats. For å legge til en ny test trenger du bare å legge til en ny eksempellinje.

Beste praksis for å skrive scenarioomriss

• Inkluder virkelige data: Teamet har mindre sannsynlighet for å overse grensebetingelser eller skjult informasjon når det bruker brukstilfeller fra virkeligheten for å forstå atferd.
• Kommuniser målet ved hjelp av forretningsrelatert terminologi for å hjelpe teamets ikke-tekniske og tekniske interessenter med å forstå hverandre bedre.
• Forklar hensikten din i stedet for hvordan den skal implementeres; trinnforklaringene bør være minst mulig tekniske. De bør fokusere mer på systemets funksjoner enn på hvordan det fungerer
• Behold bare det som er nødvendig: For å holde scenarioet engasjerende for alle deltakerne bør du ikke overfylle det med unødvendige trinn.

Hovedpunkter

Cucumber er et flott samarbeidsverktøy for ikke-tekniske personer, utviklere og testere. Det er et BDD-verktøy som gir skriftlige spesifikasjoner og kan brukes i testing. Flere scenarioer kan skrives for å demonstrere ulike krav.

Det er en god idé å bruke scenarioomriss med separate verdisett angitt gjennom eksempeltabellen når scenarioene har de samme trinnene, men krever ulike dataverdier som inndata eller utdata.

Abonner på nyhetsbrevet til The CTO Club for mer innsikt.