iOS-enheder har stadig en betydelig andel af mobilmarkedet, idet de tegner sig for op til 22 procent af salget på globalt plan. Da mange hengivne kunder vender tilbage efter nye Apple-produkter, er der også en stor efterspørgsel efter iOS-applikationer. I denne artikel vil vi se på at sikre kvaliteten af iOS-apps ved at stræbe efter brugen af bedste praksis ved hjælp af Appium-, Cucumber- og Serenity-værktøjer.

Struktur

Sideobjektmodellen er en af de bedste tilgange til testning, som QA-ingeniører kan anvende i et testautomatiseringsprojekt. Det er sådan en måde at strukturere koden i et automatiseringsprojekt på, som forbedrer kodekvaliteten og læsbarheden, testvedligeholdelsen og oven i købet er det en fantastisk måde at undgå kaos på. Den grundlæggende idé bag den kommer til at bestå i at holde alle referencer til mobile elementer og metoder, der udfører operationer på dem, i én klassefil for hver side eller skærm i appen (eller webside for ikke-native webapplikationer).

Hvad er fordelene ved denne tilgang, spørger du måske? For det første gør det automatiseringen virkelig ligetil. Dybest set betyder det, at vi skal finde elementer i vores iOS-app via inspektøren og derefter udføre operationer på dem. En anden væsentlig fordel er den sammenhængende struktur i projektet, som gør det muligt for enhver at navigere hurtigt i det.

Lad os tage et eksempel på en app, der indeholder opskrifter. Den viser standardkogebogen med grundlæggende opskrifter ved opstart, hvilket vil være vores første side. Derfra kan en bruger navigere til enhver tilgængelig opskrift og dermed markere en anden side. Derudover giver appen også mulighed for at gennemse andre kogebøger eller købe premium-kogebøger, hvilket gør den til den tredje side og dermed – en sideobjektfil.

Sådan skal vi oprette tilsvarende trin definitionsfiler. Dette er ikke en obligatorisk praksis, men det skaber unødigt kaos at holde alle trindefinitioner ét sted.

Ved oprettelsen af dine sider og trindefinitionsklassefiler anbefales det at vælge navne, der er relateret til den side (app-skærm), hvis indhold du vil arbejde med. At navngive disse filer efter en funktion eller et scenarie kan ved første øjekast virke rigtigt, men efterhånden som projektet udvides, vil du bemærke mere og mere rod i dets struktur. Ved at vedtage sidebetegnelseskonventionen sikrer du, at alle, der er involveret i projektet, kan blive bekendt med den med det samme og begynde at samarbejde om den på ingen tid. En sådan praksis bidrager også til genbrugelighed af kode – enten trindefinitioner eller metoder/funktioner.
I modsætning til de nævnte trin- og trin definitionsfiler skal Cucumber feature-filer navngives efter en funktion, som de verificerer. Smart, ikke sandt? Og igen vil en strukturering af dem i mapper, der er navngivet i forhold til et bestemt område i den applikation, der testes, gøre strukturen mere meningsfuld.
Serenitys grundlæggende koncept er at være en “levende dokumentation”. Derfor hjælper det teamet og interessenterne med at forstå rapporterne og hele projektet bedre ved at give testscenarier og funktionsfiler passende navne.

En anden ingrediens, der udvider fordelene ved Page Object Model i testautomatiseringsprojektet, er PageFactory. Det er et værktøj, der hjælper dig med at reducere kodningsarbejdet og nemt sætte MobileElements-lokatorer i kode ved hjælp af @FindBy-notationen. Derfra er det meget enklere at finde elementer, så Appium kan interagere med dem i tests.

Assertion

Afvikling af tests via Appium kan være meget ressourcekrævende. For at gøre det lettere for din MacOS-maskine, der kører test på din iOS-enhed, skal du sørge for, at du ikke konstant bekræfter synligheden af alle objekter på en side. Denne praksis øger testudførelsestiden betydeligt, hvilket normalt ikke er det mest ønskværdige.

Hvad mere er, når du skal kontrollere, om et element er synligt, aktiveret, klikbart eller noget derimellem – så prøv at undgå at lokalisere mobile elementer ved hjælp af Xpath. Appium-inspektørens tip har en gyldig pointe! Du bør gøre hvad du kan for at overbevise udviklingsteamet om at gøre en ekstra indsats og tildele unikke ID’er og navne til elementerne i appen. Dette vil ikke kun gøre automatiseringstestning nemmere og hurtigere, men vil følgelig gøre dit arbejde som tester mere effektivt, hvilket i sidste ende vil resultere i at øge den overordnede kvalitet af produktet. Og det er derfor, vi er her. For ikke at nævne, at vedligeholdelsen af testene (f.eks. skift til forskellige lokalisatorer, når det er nødvendigt) vil blive meget sjovere.

Forstå trinene

Et andet aspekt af opsætningen af denne slags projekter handler om at drage fordel af Cucumber og bruge Gherkin-sproget.

Gherkin implementerer en ligetil tilgang med Given, When, Then-notationen ved hjælp af de ekstra And og But, som virker ret nem at bruge. Du kan skrive stort set alt, hvad du vil, i testtrinnene i dine funktionsfiler. I sidste ende vil de kaldte metoder udføre handlinger.

Men grunden til at bruge Behavior Driven Development-tilgangen og selve Cucumber er at sætte de ikke-tekniske personer, der er involveret i projektet, i stand til at forstå, hvad der foregår i testfeltet. Ikke kun det, at det at skrive testscenarier på Given/When/Then-måden kan også virke til din fordel. Sådanne testbeskrivelser på højt niveau, der leveres af kunden eller forretningsanalytikeren, vil få dig til at kode på ingen tid, forudsat at de er skrevet korrekt. Her er nogle nyttige tips:
Testscenarier skrevet i Gherkin bør fokusere på appens adfærd (deraf Behavior Driven Development).
Her er et eksempel på, hvordan man IKKE skriver testscenarier i Gherkin, der uddyber temaet om kogebogsansøgning:

Ovenstående eksempel illustrerer to dårlige praksisser, som vi bør undgå: Det fokuserer på implementeringen i stedet for adfærd, og det bruger hårdtkodede værdier i stedet for at skrive testtrin på en sådan måde, at det muliggør genanvendelighed ved at ændre værdier inden for et trin.

Derfor bør et korrekt scenarie vedrørende køb af en kogebog i vores eksempelapp se ud som:

Et andet eksempel:

Vedtagelse af denne tilgang betyder mindre arbejde med at oprette og kode testtrinnene, når implementeringen af en bestemt funktion ændres.

Afhængigt af hovednotationen Given/When/Then understøtter Cucumber brugen af konjunktionstrin. Ved at bruge And og But-trinsnotationerne bliver testtrinnene mere generelle og genanvendelige, hvilket resulterer i, at der skrives mindre kode og opretholdes orden i projektet. Her er et grundlæggende eksempel:

Hvis du koder ovenstående “Given”-trin til at finde vores opskriftselement ved at søge på dets navn, kan du genbruge det mange gange ved blot at ændre strengværdien i trinnet (forudsat at du koder trindefinitionen korrekt senere). Derudover kan ‘And’-trinnet være en del af ethvert testscenarie, der involverer en sådan handling.

Samlet det hele sammen

Når man har oprettet et projekt ved hjælp af de ovenfor beskrevne fremgangsmåder, er de mest synlige dele af brugen af Serenity de genererede testrapporter. Når du har indført @RunWith(CucumberWithSerenity.class)-tagget i din TestRunner-klassefil, vil kørslen af testpakken resultere i, at Serenity genererer en samlet testresultatrapport, som kan være nyttig til at evaluere kvaliteten af den app, der testes, og præsentere produktets status for interessenterne eller udviklingsteamet.

Appium, Cucumber, Serenity – opsummering

Som du kan se, kan begrebet bedste praksis inden for automatiseringstestning sammenfattes i tre ord: genanvendelighed, læsbarhed og ydeevne. Genanvendelighed betyder mindre kodning og dermed mindre tid til at udføre opgaven. Læsbarhed forbedrer forståelsen, hvilket er afgørende for at sikre, at produktet gør, hvad det skal gøre. Endelig sparer ydeevne eksekveringstid og forbedrer stabiliteten. Alle tre bidrager ikke kun til kvaliteten af testautomatiseringsprojektet, men spiller også en væsentlig rolle i forbedringen af den samlede kvalitet af den leverede app.