iOS devices claimen nog steeds een belangrijk deel van de mobiele markt, met een aandeel tot 22 procent van de wereldwijde verkoop. Omdat veel toegewijde klanten terugkomen voor nieuwe Apple producten, is er ook een grote vraag naar iOS applicaties. In dit artikel gaan we kijken naar het waarborgen van de kwaliteit van iOS apps, waarbij we streven naar het gebruik van best practices met behulp van Appium, Cucumber en Serenity tools.

Structuur

Het Page Object Model is een van de beste benaderingen van testen die QA-engineers kunnen toepassen op een testautomatiseringsproject. Het is zo’n manier om de code in een automatiseringsproject te structureren dat de kwaliteit en leesbaarheid van de code verbetert, het testonderhoud verbetert en bovendien is het een geweldige manier om chaos te vermijden. Het basisidee erachter komt erop neer dat alle verwijzingen naar mobiele elementen en methoden die bewerkingen op hen uitvoeren in één klassebestand voor elke pagina of scherm van de app (of webpagina voor niet-native webapplicaties) worden bijgehouden.

Wat zijn de voordelen van deze aanpak, zult u zich misschien afvragen? Ten eerste, het maakt automatisering heel eenvoudig. In principe betekent het het vinden van elementen in onze iOS app via de inspector en vervolgens het uitvoeren van operaties op hen. Een ander groot voordeel is de coherente structuur van het project waardoor iedereen er snel doorheen kan navigeren.

Laten we eens een voorbeeld nemen van een app die recepten bevat. Het toont het standaard kookboek met basisrecepten bij het opstarten, wat onze eerste pagina zal zijn. Van daaruit kan een gebruiker naar elk beschikbaar recept navigeren, waarmee een tweede pagina wordt gemarkeerd. Bovendien biedt de app de mogelijkheid om door andere kookboeken te bladeren of premium recepten aan te schaffen, waardoor het de derde pagina wordt en daarmee – een pagina object bestand.

Op dezelfde manier moeten we corresponderende stap definitie bestanden maken. Dit is niet verplicht, maar alle stapdefinities op één plaats bewaren veroorzaakt onnodige chaos.

Tijdens het maken van uw pagina’s en stapdefinitieklassebestanden is het raadzaam namen te kiezen die gerelateerd zijn aan de pagina (app-scherm) waarvan u de inhoud gaat bewerken. Deze bestanden naar een functie of scenario noemen kan op het eerste gezicht juist lijken, maar als het project groter wordt, zul je steeds meer rommel in de structuur zien. Het gebruik van de conventie voor het benoemen van pagina’s zorgt ervoor dat iedereen die bij het project betrokken is er meteen vertrouwd mee kan raken en er in een mum van tijd aan kan gaan samenwerken. Een dergelijke praktijk draagt ook bij aan herbruikbaarheid van code – hetzij stapdefinities of methoden/functies.
In tegenstelling tot de genoemde stap- en stapdefinitiebestanden, moeten de Cucumber feature-bestanden worden genoemd naar een feature die ze verifiëren. Slim, is het niet? En nogmaals, door ze te structureren in mappen met een naam die gerelateerd is aan een bepaald gebied van de applicatie die wordt getest, wordt de structuur zinvoller.
Het basisconcept van Serenity is om een ‘levende documentatie’ te zijn. Daarom helpt het geven van passende namen aan testscenario’s en feature-bestanden het team en de belanghebbenden om rapporten en het hele project beter te begrijpen.

Een ander ingrediënt dat de voordelen van het Page Object Model in het testautomatiseringsproject uitbreidt, is PageFactory. Het is een hulpmiddel dat u helpt het coderingswerk te verminderen en eenvoudig MobileElements locators in code te zetten, met behulp van @FindBy notatie. Van daaruit is het vinden van elementen voor Appium om ermee te interageren in tests veel eenvoudiger.

Assertion

Het uitvoeren van tests via Appium kan veel resources in beslag nemen. Om het makkelijker te maken voor je MacOS-machine die tests uitvoert op je iOS-apparaat, moet je ervoor zorgen dat je niet constant de zichtbaarheid van alle objecten op een pagina controleert. Deze praktijk verhoogt de testuitvoeringstijd aanzienlijk, wat meestal niet het meest wenselijke is.

Wat meer is, wanneer je wel moet controleren of een element zichtbaar, ingeschakeld, klikbaar, of iets daartussenin is – probeer dan te voorkomen dat mobiele elementen worden gelokaliseerd met behulp van Xpath. De Appium inspector tip heeft een geldig punt! Je moet doen wat je kunt om het ontwikkelteam te overtuigen om een extra inspanning te leveren en unieke ID’s en namen toe te kennen aan de elementen in de app. Dit zal niet alleen het automatiseren van het testen makkelijker en sneller maken, het zal ook je werk als tester effectiever maken, wat uiteindelijk zal resulteren in het verhogen van de algehele kwaliteit van het product. En dat is waarom we hier zijn. Om nog maar te zwijgen van het feit dat het onderhoud van de tests (b.v. het overschakelen op andere locators wanneer dat nodig is) veel aangenamer zal worden.

De stappen begrijpen

Een ander aspect van het opzetten van dit soort projecten komt neer op het profiteren van Cucumber en het gebruik van de taal Gherkin.

Gherkin implementeert een eenvoudige aanpak met de notatie Given, When, Then met behulp van de extra And en But, die vrij eenvoudig te gebruiken lijkt. Je kunt zo’n beetje alles schrijven wat je wilt in de teststappen van je functiebestanden. Uiteindelijk gaan de aangeroepen methoden acties uitvoeren.

Maar de reden voor het gebruik van de Behavior Driven Development aanpak en Cucumber zelf is het mogelijk maken voor de niet-tech mensen die betrokken zijn bij het project om te begrijpen wat er gaande is in het testveld. Niet alleen dat, het schrijven van testscenario’s op een Given/When/Then manier kan ook in je voordeel werken. Dergelijke high-level test beschrijvingen geleverd door de klant of business analist zal je in een mum van tijd aan het coderen krijgen, op voorwaarde dat ze goed geschreven zijn. Hier zijn enkele nuttige tips:
Testscenario’s geschreven in Gherkin moeten zich richten op het gedrag van de app (vandaar Behavior Driven Development).
Hier volgt een voorbeeld van hoe testscenario’s NIET in Gherkin moeten worden geschreven, waarbij het thema kookboektoepassing verder wordt uitgediept:

Het bovenstaande voorbeeld illustreert twee slechte praktijken die we moeten vermijden: Het richt zich op de implementatie in plaats van op het gedrag en het gebruikt hard-coded waarden in plaats van teststappen zo te schrijven dat herbruikbaarheid mogelijk is door waarden binnen een stap te wijzigen.

Daarom zou een goed scenario met betrekking tot de aanschaf van een kookboek in onze voorbeeld-app er als volgt uit moeten zien:

Een ander voorbeeld:

Het volgen van deze aanpak betekent minder werk bij het maken en coderen van de teststappen wanneer de implementatie van een bepaalde functie verandert.

Naast de hoofdnotatie Given/When/Then, ondersteunt Cucumber het gebruik van conjunction steps. Het gebruik van En en Maar stap notaties maakt de teststappen meer algemeen en herbruikbaar, wat resulteert in het schrijven van minder code en het handhaven van orde binnen het project. Hier volgt een basisvoorbeeld:

Als je dus de bovenstaande ‘Given’-stap codeert om ons recept-element te lokaliseren door de naam ervan te zoeken, kun je deze stap vele malen hergebruiken door alleen de tekenreekswaarde in de stap te wijzigen (mits je de stapdefinitie later goed codeert). Bovendien kan de ‘And’-stap deel uitmaken van elk testscenario waarin een dergelijke actie wordt uitgevoerd.

Het geheel samenvoegen

Nadat u een project hebt opgezet met gebruikmaking van de hierboven beschreven praktijken, zijn de gegenereerde testrapporten het meest zichtbare onderdeel van het gebruik van Serenity. Nadat u de tag @RunWith(CucumberWithSerenity.class) in uw TestRunner-klassebestand hebt overgenomen, zal het uitvoeren van de testsuite ertoe leiden dat Serenity een geaggregeerd testresultatenrapport genereert, dat nuttig kan zijn bij het evalueren van de kwaliteit van de geteste app en het presenteren van de status van het product aan de belanghebbenden of het ontwikkelingsteam.

Appium, Cucumber, Serenity – Samenvatting

Zoals u ziet, kan het concept van best practices bij geautomatiseerd testen in drie woorden worden samengevat: herbruikbaarheid, leesbaarheid en prestaties. Herbruikbaarheid betekent minder coderen, waardoor er minder tijd nodig is om de klus te klaren. Leesbaarheid verbetert het begrip, wat cruciaal is om te verzekeren dat het product doet wat het moet doen. Prestatie, ten slotte, bespaart uitvoeringstijd en verbetert de stabiliteit. Alle drie dragen ze niet alleen bij aan de kwaliteit van het testautomatiseringsproject, maar spelen ze ook een belangrijke rol bij het verbeteren van de algehele kwaliteit van de opgeleverde app.