Datadrevet eller parametreret test med Spock Framework

data driven parameterized testing with spock framework

Udforsk måderne til at skrive datadrevne eller parametriserede tests med Spock Framework:

Heri Gratis Spock-træningsvejledningsserie , vi udforskede alt om Enhedstest i Spock og test inventar, påstande og rapportering i vores tidligere tutorial.

I denne vejledning vil vi forsøge at forstå, hvad parametrerede tests er, og hvordan du kan udnytte de indbyggede funktioner i Spock til at opnå datadrevet test.

Lad os begynde!!

Se videoundervisningen

Hvad du vil lære:

• Hvad er parametriserede tests?
• Skrivning af parametriserede tests med Spock
  • Hvor: blokere
  • Brug af data
• Livscyklus for 'hvor' -blokken
• Tips og tricks
• Konklusion
• Anbefalet læsning

Hvad er parametriserede tests?

For alle, der har arbejdet med automatisering / enhedstest, er datadrevet test ikke et nyt begreb.

Parameteriserede tests er intet andet end de er nogen form for tests, der deler den samme eksekveringslogik og kun adskiller sig i inputdataene og resultatet i nogle tilfælde.

Eksempel: Antag, at du har et lommeregnerprogram, for at kunne teste funktionaliteten fuldstændigt, vil du måske køre dine tests mod forskellige indgangssæt.

Eksempel: Negative værdier, brøktal, normale heltal, heltal nærmer sig det maksimalt tilladte interval osv. Uanset hvilke inputværdier du har, vil du køre den samme eksekveringslogik.

En anden god grund til at skrive parametriserede tests er, at den ikke bare tester en glad sti, men snarere også tester fejlsti eller negative scenarier.

Eksempel: Antag, at der er et program, der returnerer, om en given filtypenavn er gyldig eller ej. Datadrevne test kan hurtigt gøre det muligt for udvikleren at udføre test for understøttede filtypenavne og eventuelle fejlscenarier eller negative inputtests.

Nu kan du traditionelt tænke på at skrive eller kopiere testene til flere inputværdier, men det er ikke den rigtige eller smarte måde at opnå denne form for testudførelse på. Da antallet af tests begynder at stige i din app, bliver disse tests desuden vanskelige at vedligeholde.

Skrivning af parametriserede tests med Spock

Hvor: blokere

Hvor-blokken i en Spock-test er den blok, der indeholder data til den parametriserede test. Det kan valgfrit indeholde både input- og forventede outputværdier. Et vigtigt punkt at bemærke om denne blok er, at dette skal være den sidste blok i en Spock-test.

Når det er sagt, kan det kombineres med alle de andre blokke som givet, når og da, men skal være den sidste blok.

Lad os se på et eksempel for at forstå det bedre

Vi bruger et lommeregnerprogram, der tager 2 inputparametre og returnerer summen af ​​de leverede input. Vi skriver en parametreret test, der leverer flere input og forventede outputværdier.

I ovenstående kodeeksempel kan du se følgende:

1. 'Hvor' -blok, der indeholder data, som testen skal køre.
2. 'Hvor' -blokken er den sidste blok i testen.
3. 'Hvor' kombineres med de andre blokke, dvs. angivet, hvornår og derefter.
4. Datarepræsentation er et specielt format kaldet datatabeller, som vi vil se detaljeret i de kommende sektioner af denne vejledning.
5. Overskriftsrække med data er i det væsentlige egenskaberne / inputvariablerne, som kan bruges direkte i testen. For eksempel. Se udsagnet i 'når' -blokken, hvor vi har brugt direkte input1 og input2 som inputparametre uden at definere dem eksplicit.

Brug af data

Lad os prøve at forstå datatabeller i detaljer nu. Hver linje i datatabellen repræsenterer data for et individuelt scenario (testudførelse).

Efter konvention dvs. inputværdier er forud for et enkelt rør ('|'), mens outputværdier er forud for dobbeltrør ('||'). Dette har ingen logisk betydning, men det er konvention og forbedrer læsbarheden. Således gælder begge eksemplerne nedenfor.

Overskriftsrækken, som vist ovenfor, har et navn til hver af de parametre, der leveres som data til test. Det er vigtigt at bemærke her, at disse parameternavne ikke bør kollidere med nogen eksisterende lokale / globale variabler i testen, ellers vil der være kompileringsfejl for at løse variabelnavne.

Et vigtigt punkt at bemærke ved brug af datatabeller er, at der kræves mindst 2 kolonner. Hvis du bare har brug for en kolonne, så er en tom kolonne med værdier som understregningstegn en løsning som nedenfor.

Fordelen ved dette format er enkelhed, læsbarhed og udvidelse. Tilføjelse af et nyt dataindgang er så simpelt som at tilføje en ny række med dataværdier.

Et andet punkt at bemærke her er, at datatabeller kan bruges til at indeholde enhver type variabler, klasser, objekter, enums osv., Der gør det endnu mere kraftfuldt. Da groovy er et valgfrit indtastet sprog, hvis en eksplicit type ikke er specificeret, betyder variablerne i datatabellen afhængigt af den leverede datatype.

Lad os se en anden Eksempel ved hjælp af datatabeller med en liste over strenge som input og output som et antal elementer i strengen.

I ovenstående eksempel kan du bemærke, at vi har leveret input som en matrixliste over strenge, og output er størrelsen på denne array-liste. Således giver det stor fleksibilitet at have inputdata af forskellige typer.

Du kan også blot nævne ethvert udtryk, der også direkte returnerer data af den respektive inputtype og bruger i datatabeller.

Livscyklus for 'hvor' -blokken

For tests, der indeholder, hvor blok- og datasampler i form af datatabeller, repræsenterer hver række data en udførelse af testmetoden.

For eksempel, hvis der er 5 rækker med data, og testen indeholder 'givet' og 'hvornår' blokke, så for en sådan datarække udføres testblokkene en gang. Så samlet set vil der være i alt 5 henrettelser af testmetoden.

Tips og tricks

Lad os se nogle tip og tricks til parametriserede tests, mens vi arbejder med disse datatabeller.

# 1) Visning af resultaterne af individuel rækkeudførelse separat. Som vi så i sektionen livscyklus, er der for hver række data en udførelse af testkoden. For at få disse rækker eller resultater vist separat for hver sådan række kan '@Unroll' -notering bruges til sådanne tests.

Lad os prøve at forstå dette med et eksempel:

Vi bruger den samme lommeregnerapplikation med 3 sæt inputdata, der leveres til metoden under test.

spørgsmål om c ++ -kodning af interview

Uden '@Unroll' -kommentar, lad os se, hvordan ser resultatet ud i terminalen (såvel som de html-baserede rapporter). Med denne form for output bliver det svært at finde ud af, hvilket sæt input der fik testen til at mislykkes.

Lad os nu se, hvordan testoutputtet rapporteres separat for hver række efter tilføjelse af '@Unroll' -notering til testmetoden (som har datatabeller som datainput).

#to) Lad os nu forstå, hvordan vi tilføjer meningsfuld info til disse datadrevne tests (i stedet for nogle automatisk tilføjede indekser som i skærmbilledet ovenfor).

Vi kan bruge pladsholdere til input- og outputegenskaberne (pr. Datatabel), og så kan vi se de værdier, der er befolket i testnavne med data fra datatabeller.

Lad os bruge det samme eksempel og opdatere testnavnet for at hente data fra input og forventet output som nævnt i datatabellerne:

Lad os nu se, hvordan ser output ud i terminalen og de HTML-baserede rapporter:

Så som du kan se her, vises dataene fra input og output nu sammen med testnavne, når de bliver udført. På denne måde gør det fejlfinding og fejlretning meget lettere, da det tydeligt angiver, hvilket input der fik testen til at mislykkes eller opføre sig forkert.

Konklusion

I denne vejledning lærte vi om at skrive parametriserede tests med Spock-rammen. Vi diskuterede også forskellige funktioner i datatabeller og hvordan de kan bruges.

Tjek vores kommende vejledning for at vide, hvordan du bruger Mocks and Stubs med Spock !!

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

• Skrivningstest med Spock Framework
• Spock Interview-spørgsmål med svar (mest populære)
• Spock til integration og funktionel test med selen
• Spock Mocking og Stubbing (Eksempler med videotutorials)
• Spock Tutorial: Test med Spock og Groovy
• Datadrevet ramme i Selen WebDriver ved hjælp af Apache POI
• Sådan udføres datadrevet test ved hjælp af TestComplete-værktøjet
• Sådan fungerer datadrevet test (eksempler på QTP og selen)