iOS-enheter har fortfarande en betydande del av mobilmarknaden, med upp till 22 procent av försäljningen globalt. Eftersom många hängivna kunder återkommer för nya Apple-produkter finns det också en stor efterfrågan på iOS-applikationer. I den här artikeln kommer vi att titta på hur vi säkerställer kvaliteten på iOS-applikationer genom att sträva efter att använda bästa praxis med hjälp av verktygen Appium, Cucumber och Serenity.

Struktur

The Page Object Model är ett av de bästa tillvägagångssätten för testning som QA-ingenjörer kan tillämpa på ett testautomatiseringsprojekt. Det är ett sådant sätt att strukturera koden i ett automatiseringsprojekt som förbättrar kodkvaliteten och läsbarheten, testunderhållet och dessutom är det ett utmärkt sätt att undvika kaos. Den grundläggande idén bakom det kommer att hålla alla referenser till mobila element och metoder som utför operationer på dem i en klassfil för varje sida eller skärm i appen (eller webbsida för icke-nativa webbapplikationer).

Vad är fördelarna med det här tillvägagångssättet, kanske du frågar dig? För det första gör det automatiseringen väldigt enkel. I grund och botten innebär det att hitta element i vår iOS-app via inspektorn och sedan utföra operationer på dem. En annan viktig fördel är projektets sammanhängande struktur som gör att vem som helst snabbt kan navigera i det.

Låt oss ta ett exempel på en app som innehåller recept. Den visar standardkokboken med grundläggande recept vid uppstart, vilket kommer att bli vår första sida. Därifrån kan en användare navigera till alla tillgängliga recept, vilket markerar en andra sida. Dessutom kan man i appen bläddra i andra kokböcker eller köpa premiumkokböcker, vilket gör den till den tredje sidan och följaktligen – en sidobjektsfil.

På samma sätt bör vi skapa motsvarande stegdefinitionsfiler. Detta är inte obligatoriskt, men att hålla alla stegdefinitioner på ett ställe orsakar onödigt kaos.

När du skapar dina sidor och stegdefinitionsklassfiler rekommenderas det att du väljer namn som är relaterade till den sida (appskärmen) vars innehåll du kommer att arbeta med. Att namnge dessa filer efter en funktion eller ett scenario kan verka rätt vid första anblicken, men när projektet expanderar kommer du att märka att det blir mer och mer rörigt i dess struktur. Genom att anta sidnamnskonventionen säkerställs att alla som är involverade i projektet kan bekanta sig med den direkt och börja samarbeta med den på nolltid. En sådan praxis bidrar också till att koden kan återanvändas – antingen stegdefinitioner eller metoder/funktioner.
I motsats till de nämnda stegen och stegdefinitionsfilerna bör Cucumber-funktionsfilerna namnges efter en funktion som de verifierar. Smart, eller hur? Och återigen, genom att strukturera dem i kataloger som är namngivna i förhållande till ett visst område i den applikation som testas kommer strukturen att bli mer meningsfull.
Serenitys grundkoncept är att vara en ”levande dokumentation”. Att ge testscenarier och funktionsfiler lämpliga namn hjälper därför teamet och intressenterna att förstå rapporterna och hela projektet bättre.

En annan ingrediens som utökar fördelarna med Page Object Model i testautomatiseringsprojektet är PageFactory. Det är ett verktyg som hjälper dig att minska kodningsarbetet och enkelt lägga in MobileElements lokatorer i koden med hjälp av @FindBy-notationen. Därifrån är det mycket enklare att hitta element för att Appium ska kunna interagera med dem i tester.

Assertion

Att köra tester via Appium kan vara mycket resurskrävande. För att underlätta för din MacOS-maskin som kör tester på din iOS-enhet kan du se till att du inte hela tiden bekräftar synligheten för alla objekt på en sida. Detta ökar testets exekveringstid avsevärt, vilket vanligtvis inte är det mest önskvärda.

Och när du måste kontrollera om ett element är synligt, aktiverat, klickbart eller något däremellan – försök att undvika att lokalisera mobila element med hjälp av Xpath. Tipset om Appium-inspektören har en giltig poäng! Du bör göra vad du kan för att övertyga utvecklingsteamet om att göra en extra ansträngning och tilldela unika ID och namn till elementen i appen. Detta kommer inte bara att göra automatiseringstester enklare och snabbare, utan följaktligen göra ditt arbete som testare mer effektivt, vilket i slutändan leder till att produktens övergripande kvalitet ökar. Och det är därför vi är här. För att inte tala om att underhållet av testerna (t.ex. att byta till olika lokaliserare vid behov) kommer att bli mycket roligare.

Förstå stegen

En annan aspekt av att sätta upp den här typen av projekt handlar om att dra nytta av Cucumber och att använda Gherkin-språket.

Gherkin implementerar ett rakt tillvägagångssätt med Given, When, Then-notationen med hjälp av de ytterligare And och But, som verkar ganska lätt att använda. Du kan skriva i stort sett vad du vill i teststegen i dina funktionsfiler. I slutändan kommer de anropade metoderna att utföra åtgärder.

Men anledningen till att använda metoden för beteendestyrd utveckling och Cucumber i sig är att göra det möjligt för de icke-tekniska personer som är involverade i projektet att förstå vad som händer i testfältet. Att skriva testscenarier på Given/When/Then-sättet kan också vara till din fördel. Sådana testbeskrivningar på hög nivå som levereras av kunden eller affärsanalytikern kommer att få dig att koda på nolltid, förutsatt att de är skrivna på rätt sätt. Här är några användbara tips:
Testscenarier som skrivs i Gherkin bör fokusera på appens beteende (därav Behavior Driven Development).
Här är ett exempel på hur man INTE skriver testscenarier i Gherkin, vilket ytterligare utforskar temat kokbokstillämpning:

Ovanstående exempel illustrerar två dåliga metoder som vi bör undvika: Det fokuserar på implementationen istället för beteendet och det använder hårt kodade värden istället för att skriva teststeg på ett sådant sätt att det möjliggör återanvändning genom att ändra värden inom ett steg.

Det korrekta scenariot gällande köp av en kokbok i vår exempelapp bör därför se ut så här:

Ett annat exempel:

Anslutar man sig till det här tillvägagångssättet innebär det mindre arbete med att skapa och koda teststegen närhelst implementationen av en viss funktion ändras.

Förutom huvudnotationen Given/When/Then har Cucumber stöd för användning av konjunktionssteg. Genom att använda notationerna And och But steg blir teststegen mer generella och återanvändbara, vilket resulterar i att man skriver mindre kod och upprätthåller ordning i projektet. Här är ett grundläggande exempel:

Om du kodar steget Given ovan för att hitta vårt receptelement genom att söka på dess namn kan du återanvända det många gånger genom att bara ändra strängvärdet i steget (förutsatt att du kodar stegdefinitionen korrekt senare). Dessutom kan steget ”And” vara en del av alla testscenarier som involverar en sådan åtgärd.

Sätt ihop allt

Efter att ha satt upp ett projekt med hjälp av de metoder som beskrivs ovan är de mest synliga delarna av att använda Serenity de genererade testrapporterna. Efter att ha antagit taggen @RunWith(CucumberWithSerenity.class) i din TestRunner-klassfil, kommer testsviten att köras och Serenity kommer att generera en sammanställd testresultatrapport, som kan vara användbar för att utvärdera kvaliteten på den testade appen och presentera produktens status för intressenterna eller utvecklingsteamet.

Appium, Cucumber, Serenity – Sammanfattning

Som du ser kan begreppet bästa praxis för automatiseringstestning sammanfattas med tre ord: återanvändbarhet, läsbarhet och prestanda. Återanvändbarhet innebär mindre kodning, vilket följaktligen minskar den tid som behövs för att slutföra jobbet. Läsbarheten förbättrar förståelsen, vilket är avgörande för att säkerställa att produkten gör vad den ska göra. Slutligen sparar prestanda tid och förbättrar stabiliteten. Alla tre bidrar inte bara till kvaliteten på programautomatiseringsprojektet utan har en betydande roll för att förbättra den övergripande kvaliteten på den levererade appen.