Implementering af Cucumber-scenarieoversigter i BDD-frameworks

Adfærdsdrevet udvikling (BDD) er en agil softwareudviklingspraksis, der forbedrer samarbejdet mellem interessenter og udviklere ved at bruge et enkelt, domænespecifikt sprog til at beskrive systemets adfærd. 

Et af de mest effektive værktøjer i BDD er Cucumber, som bruges til at skrive tydelige specifikationer. Det kan også bruges til test med de mest almindeligt anvendte programmeringssprog som Java, Python eller C# og kan integreres med UI-rammeværker som Selenium eller bruges til API-test.

Scenarieoversigter er en del af Cucumbers Gherkin-syntaks, som bruges til at skrive eksekverbare specifikationer. I modsætning til almindelige scenarier, der definerer ét konkret eksempel, gør scenarieoversigter det muligt at specificere flere eksempler i tabelformat. 

Forskelle mellem scenarier og scenarieoversigter

Scenarier i Cucumber repræsenterer en testsag skrevet i den grundlæggende form givet-når-så. Gherkin-sproget gør det muligt at skrive disse testscenarier på almindeligt engelsk (og andre sprog), så de nemt kan forstås og endda skrives af personer uden teknisk baggrund. Trindefinitionerne, som repræsenterer implementeringen af trinnene, oprettes i separate filer. 

For visse funktioner giver det mening at gentage det samme scenarie med forskellige testdata – det kender du måske som datadrevet test. I Cucumber gøres dette ved at bruge en scenarieoversigt med en eksempeltabel, der indeholder de datasæt, der skal bruges. Hvert eksempel tæller som en separat test.  

Syntaks for Cucumber-scenarieoversigter

Et typisk Cucumber-projekt indeholder funktionsfiler, hvor Cucumber-testene defineres, samt trindefinitionsfiler med implementeringerne af trinnene. 

En funktionsfil bør repræsentere en kravspecifikation samt de scenarier, der bruges til at teste den. Den grundlæggende syntaks for et enkelt Cucumber-scenarie er:

Scenariet kan også indeholde variabler, som vil blive behandlet som sådanne i trindefinitionen.

Værdierne “test”, “ugyldig” og “Ugyldigt login” vil blive behandlet som variabler. Lad os nu se, hvad der sker, når vi vil prøve forskellige kombinationer af de angivne variabler – vi kunne ende med flere scenarier, der er identiske bortset fra variabelværdierne, eller bruge scenarieoversigten, som gør det muligt at bruge en tabel, hvor vi definerer de forskellige datakombinationer:

Datakombinationen skrives under nøgleordet “Eksempler” i en tabel. Tabellernes overskrifter er variabelnavnene, og hver række repræsenterer datakombinationen. Hvert eksempel i en Cucumber-funktionsfil vil blive behandlet som en individuel testsag. 

Eksempeltabeller kontra datatabeller

Eksempel- og datatabeller kan ligne hinanden, men de tjener forskellige formål. Den primære forskel er, at eksempler bruges til at implementere datadrevne scenarier, mens datatabeller bruges, når scenariets trin skal anvende flere variabler.

En datatabel kan bruges sådan:

eller sådan:

Datatabeller er særligt nyttige, når trinnene kræver flere variabler, og de er lettere at læse end når hver værdi skrives inde i trinnet.  

Arbejde med datatabeller og scenarieoversigt 

Datatabeller og scenarieoversigter kan også fungere sammen. Variablens navn angives i datatabellen og genbruges derefter i eksempeltabellen.

Fordele ved at bruge scenarieoversigter

Scenarieoversigter kan fortolkes som en "skabelon" for en testsag. Når de først er implementeret i en testramme, udfører de det samme scenarie med forskellige datasæt.

Fordelen er, at der er færre linjer Gherkin og mindre gentagelse. Det betyder, at når der er behov for en ændring i det fælles scenarie, skal den kun foretages én gang, og ændringen anvendes på alle kombinationer af testdata.

En anden fordel ved scenarieoversigter er, at de kan give større dækning med et minimum af arbejde. Hvis du vil tilføje en ny test, skal du tilføje en ny eksempellinje.

Bedste praksis for at skrive scenarieoversigter

• Inddrag virkelige data: Teamet overser mindre sandsynligt randtilfælde eller skjulte oplysninger, når det bruger anvendelsestilfælde fra virkeligheden til at forstå adfærd.
• Kommunikér målet ved hjælp af forretningsterminologi for at hjælpe teamets ikke-tekniske og tekniske interessenter med at forstå hinanden bedre.
• Forklar din hensigt i stedet for, hvordan den implementeres; forklaringerne af trinnene bør være så lidt tekniske som muligt. De bør fokusere mere på systemets funktioner end på dets drift
• Behold kun det nødvendige: For at holde scenariet engagerende for alle deltagere bør du ikke overfylde det med unødvendige trin.

Vigtigste pointer

Cucumber er et fremragende samarbejdsværktøj mellem ikke-tekniske personer, udviklere og testere. Det er et BDD-værktøj, der leverer skriftlige specifikationer og kan bruges til test. Der kan skrives flere scenarier for at demonstrere forskellige krav.

Det er en god idé at bruge en scenarieoversigt med forskellige sæt værdier, der angives via eksempeltabellen, når scenarierne har de samme trin, men kræver forskellige dataværdier som input eller output.

Tilmeld dig The CTO Clubs nyhedsbrev for at få flere indsigter.