Automatisering af UI-testning på iOS er blevet lige så nemt som at skrive enhedstest, lige siden Apple introducerede XCUI-rammen. I dette indlæg vil jeg tale om, hvordan XCUI, kombineret med lagdelt design, kan hjælpe med nemt at automatisere applikationer, især dem med flere tilpassede UI-elementer. En af de applikationer, hvor vi har brugt dette i stor udstrækning, er VMware Boxer, en virksomhedsapplikation fra VMware, der samler tre vigtige funktioner – e-mail, kalender og kontakter. VMware Boxer bruger flere typer af UI-elementer fra native UITableView til stærkt tilpassede visuelle elementer.
Det antages, at læserne har en grundlæggende forståelse af Xcode, Objective C, Swift, XCUI-rammen og Apples udviklingsøkosystem generelt. Hvis du er ny i XCUI, bør du først starte her.
Som ethvert andet UI-automatiseringsprojekt startede vores team med et spørgsmål om, hvilken automatiseringsramme der skulle bruges. Vi havde brugt SeeTest. Vi så dog dette som en mulighed for at revidere vores automatiseringsstrategi i betragtning af den nye, komplekse funktionalitet, der blev tilføjet i VMware Boxer, antallet af produkter i VMwares økosystem og integrationstest på tværs af disse produkter. Nedenfor var de valg, vi overvejede-
1. Fortsæt med SeeTest
2. Earl Grey
3. XCUI
Mens SeeTest havde kapacitet til at håndtere vores umiddelbare behov for automatisering, var der en selvstændig udfordring at tage fat på. Det krævede, at vi skulle indføre en ny teknologistak. Det ville kræve yderligere uddannelse af iOS-udviklere og dedikerede eksperter til at vedligeholde automatiseringssystemet.
Hvad med Appium? Vi overvejede ikke Appium af de samme grunde som nævnt ovenfor for SeeTest. Appium er et godt valg, hvis vi havde hybridapps eller betydelig delt kode mellem Android og iOS.
Earl Grey 1 var et muligt valg, da det gav os mulighed for at blive i Xcode og Apples udviklingsværktøjer, og det var baseret på XCTest. Earl Grey 1 automatisering kører dog i den samme proces som den applikation, der testes. På den anden side kører Apples XCUI framework-baserede automatisering i en separat proces i forhold til den applikation, der testes. Dette er at foretrække, da den applikation, der testes, ikke bør være andet end en black box for den enhed (en automatiseringsproces eller en slutbruger), der tester dens UI.
Har den automatiserende (den, der tester) proces isoleret fra den faktiske applikation, der testes. Den applikation, der testes, bør ikke være andet end en sort boks for den automatiserende proces.
Alle nye værktøjer i Apples økosystem, der ikke er i overensstemmelse med Apples tilgang (f.eks. Earl Grey 1), kan fejle uden advarsel. En sådan tilgang kan kræve en stor indsats at vedligeholde for fortsat at kunne arbejde sammen med nyere eller fremtidige tilbud fra Apple.
Early Grey 2 tilføjede muligheden for at interagere med XCUI. Det var et forsøg på at tilpasse sig XCUI, men det havde disse kendte problemer.
I sidste ende blev XCUI det foretrukne valg. Med dette vil en udvikler have mere kontrol over automatiseringen og vil være den umiddelbare modtager af enhver innovation i Apples økosystem.
Applikation under test og XCUI-automatiseringsmodul
Hvor vi går i detaljerne, er det vigtigt at gentage, at automatiseringsmodulet, der anvender XCUI, kører som en uafhængig proces i forhold til den applikation, der er under test. Til at starte med tilføjede vi et nyt modul, som vi fremover vil referere til som Automation Module(AM). AM er et arbejdsområde, der indeholder en samling af klasser og datastrukturer, der bruges til automatisering af VMware Boxer ved hjælp af XCUI.
Accessibility Identifiers
Det er vigtigt, at applikationen udvikles med dens testbarhed i tankerne. Et af udviklerens ansvarsområder er at sikre, at hvert brugergrænsefladeelement, der udsættes for slutbrugeren, har tilgængelighedsidentifikatoren indstillet under udviklingen. Tilgængelighedsidentifikatoren er forbindelsen mellem applikationen under test og XCUI-automatiseringsprocessen.
Tilgængelighedsidentifikatoren er forbindelsen mellem applikationen under test og XCUI-automatiseringsprocessen.
Designmønster
Som tidligere nævnt er VMware Boxer en stor applikation. Valget af det designmønster, der skulle anvendes, blev truffet under hensyntagen til, at testene skulle være lette at implementere, lette at vedligeholde, genanvendelige, robuste og skalerbare. Nedenstående indhold forklarer lagene i XCUI-automatiseringsmodulets arkitektur for VMware Boxer:
Den følgende figur viser de grundlæggende byggeklodser:
Testklasser
Dette er det lag, der har de klasser, der har testmetoderne. Hensigten med dette lag er at have tests, der består af minimal kode, som kun siger det, der testes. Desuden skal udvikleren, der implementerer testene, kun tænke på det applikationsflow på højt niveau, der er nødvendigt for at teste det, der skal testes. Resten af kompleksiteten (f.eks. hvordan man navigerer til den brugergrænseflade, hvor den ønskede testning kan udføres) bør abstraheres til genanvendelige lag. Se billedet nedenfor, der viser et eksempel på en testmetode, som forklarer ovenstående hensigt – koden tester, om en Settings UI kan hjælpe med at aktivere/deaktivere en funktion, eller om den har de nødvendige switch-kontroller.
Den udvikler, der skriver testene, kan altså skrive kode, der er lige så simpel som pseudokode. I mellemtiden er det klart, at noget logik skal påberåbes fra næste lag (Flows : forklares i næste afsnit).
Flows-klasser
Flows repræsenterer en samling af klasser, der giver de funktionaliteter, der er nødvendige for forskellige testklasser. Funktionaliteterne kan omfatte opsætning af appen før udførelse af den rigtige testcase eller navigering til en bestemt del af den app, der testes. De fleste af disse funktionaliteter kan genbruges og er nødvendige i flere tests, f.eks. kræver ovenstående testcase, at 1. app’en startes, og 2. app’en startes. Vi navigerer til en skærm med indstillinger for en Feature Controller-indstillinger.
Så Flow-klasser ville blive påkaldt fra tests og ville implementere flows som “Navigate to Settings” eller “Navigate to Feature Controller Settings”.
Screens-klasser
Screens er klasser, der har en én-til-én-tilknytning til de respektive View Controllers. En View Controller kan på et højt niveau ses som en klasse, der har (i den bagvedliggende visning) UIControls og metoder, der reagerer på brugerinteraktion med disse UIControls. En skærmklasse er simpelthen en proxy-mapping af View Controller. Figuren nedenfor viser denne afbildning. Der er en celle Initial View i UI, og når brugeren trykker på denne celle, kan brugeren vælge, hvad der skal markeres som appens oprindelige visning. Figuren nedenfor viser, hvordan en Screen-klasse implementeres for at mappe ovenstående krav.
Pseudokoden for denne Screen-klasse ville se sådan ud –
// The class models the SettingFormViewController for XCUI tests.public class SettingsFormScreen {
private static let navBarId = "Boxer.Settings.NavigationBar"
private lazy var featureControllerCell = boxerApp.application.tables.cells public func navigateToFeatureController() -> Bool {
return // tap on Cell with featureControllerCellId
}
}class AccessibilityIdentifiers: NSObject {// MARK: Settings Screenstatic let featureControllerCellId = "Boxer.Settings.FeatureControllerCell"
}
hvad er boxerApp i ovenstående kode? I ovenstående kode repræsenterer boxerApp en enhed, som er en instans af BoxerApp-klassen, der indkapsler programmet under test og dets skærme. Dette forklares i det næste afsnit.
Koden ovenfor modellerer SettingFormViewController i VMware Boxer. Den konvention, der anvendes ved navngivning af klassen, er, at navnet er afledt af navnet på viewcontroller ved at erstatte suffikset ViewController med Screen. Bemærk også den bekvemmelighedsklasse, der har tilgængelighedsidentifikatorer.
Tilgængelighedsidentifikatoren er det fælles link mellem applikationen under test og XCUI-automatiseringsprocessen.
Sammensætning af det hele: VMware Boxer XCUI-automatiseringsmodul
UITest-modulet tester den kørende applikation. Det er vigtigt, at applikationsmodellen er designet således, at en instans af den app, der skal testes, er en enkelt enhed. Det betyder, at den applikation, der skal testes, skal ses som en samling af skærmklasser, der deltager i forretningsstrømme (samling af flowklasser)som påkaldes fra testene (samling af klasser)på grundlag af testens krav. Hver applikationsenhed bør have præcis én instans af hver skærmklasse, der svarer til én view controller.
Hvordan opnås dette?
En XCUITtestsuite kan opnå dette ved at indkapsle den testede applikation (XCUIApplication) i én enhed, f.eks. BoxerApp-klassen, som har en medlemsapplikation og har alle skærmbillederne for denne applikation. Figuren nedenfor forklarer denne indkapsling
Det første, den vil gøre, før XCUITest-suiten starter, er derfor at oprette en instans af BoxerApp-modulet ved hjælp af bundle-id’en for den applikation, der skal testes. Figuren nedenfor forklarer dette
Denne instans af BoxerApp (den enhed, der indkapsler XCUIApplikationen og skærmbillederne) videregives derefter af Tests::testMethod til Flows::flowMethod som første parameter.
Flows::flowMethod kalder på sin side til Screen::screenMethod og videregiver BoxerApp, hvis det er nødvendigt.
Endeligt sker interaktionen med applikationens brugergrænseflade via Screen::screenMethod.
Figuren nedenfor viser ovenstående design.
Slutning
Skrivning af XCUI-tests kan være besværligt og uoverskueligt, hvis det ikke gøres med en plan. Jeg håber, at dette indlæg giver nyttige pointer om, hvordan du kan tænke på at strukturere dit automatiseringsprojekt på en modulær, ren og lagdelt måde.
Hvad er det næste?
Jeg vil dække disse emner i den serie af historier, jeg planlægger:
XCUI : Del 2 -Interaktion med Native-applikationer på en ren måde
XCUI : Del 3 -Hvordan XCUI runtime kan interagere med den applikation, der testes, på en ren måde.
XCUI : Del 4 -Håndtering af systemadvarsler.
XCUI : Del 5 -Observation af testforløb og adgang til rapporter og optagelse af skærmbilleder.
XCUI : Del 5 -Observation af testforløb og adgang til rapporter og optagelse af skærmbilleder.