Automatisering av UI-testning på iOS har blivit lika enkelt som att skriva enhetstester ända sedan Apple introducerade XCUI-ramverket. I det här inlägget kommer jag att prata om hur XCUI, i kombination med skiktad design, kan hjälpa till att enkelt automatisera applikationer, särskilt de med flera anpassade UI-element. En sådan applikation där vi använt detta flitigt är VMware Boxer, en företagsapplikation från VMware som samlar tre viktiga funktioner – e-post, kalender och kontakter. VMware Boxer använder flera typer av UI-element, från inbyggd UITableView till mycket anpassade visuella element.
Det förutsätts att läsaren har en grundläggande förståelse för Xcode, Objective C, Swift, XCUI-ramverket och Apples utvecklingsekosystem i allmänhet. Om du är ny i XCUI bör du först börja här.
Likt alla andra UI-automatiseringsprojekt började vårt team med en fråga om vilket automatiseringsramverk som skulle användas. Vi hade använt SeeTest. Vi såg dock detta som ett tillfälle att se över vår automationsstrategi med tanke på den nya, komplexa funktionalitet som lagts till i VMware Boxer, antalet produkter i VMwares ekosystem och integrationstestning mellan dessa produkter. Nedan följer de val som vi övervägde-
1. Fortsätt med SeeTest
2. Earl Grey
3. XCUI
Medan SeeTest hade förmågan att hantera våra omedelbara behov av automatisering fanns det en oberoende utmaning att hantera. Det krävde att vi antog en ny teknikstack. Detta skulle kräva ytterligare utbildning för iOS-utvecklare och dedikerade experter för att underhålla automationssystemet.
Hur är det med Appium? Vi övervägde inte Appium av samma skäl som nämns ovan för SeeTest. Appium är ett bra val om vi hade hybridappar eller betydande delad kod mellan Android och iOS.
Earl Grey 1 var ett möjligt val, med tanke på att det gjorde det möjligt för oss att stanna i Xcode och Apples utvecklingsverktyg och att det var baserat på XCTest. Earl Grey 1 automation körs dock i samma process som applikationen som testas. Å andra sidan körs Apples XCUI-ramverksbaserade automatisering i en separat process än applikationen som testas. Detta är att föredra eftersom applikationen som testas inte bör vara något annat än en svart låda för den enhet (en automatiseringsprocess eller en slutanvändare) som testar dess användargränssnitt.
Har den automatiserande (den som testar) processen isolerad från den faktiska applikationen som testas. Den applikation som testas bör inte vara något annat än en svart låda för automatiseringsprocessen.
Varje nytt verktyg i Apples ekosystem som inte överensstämmer med Apples tillvägagångssätt (t.ex. Earl Grey 1) kan misslyckas utan förvarning. Ett sådant tillvägagångssätt kan kräva stora ansträngningar att underhålla för att fortsätta att fungera med nyare eller framtida erbjudanden från Apple.
Early Grey 2 lade till möjligheten att interagera med XCUI. Det var ett försök att anpassa sig till XCUI, men det hade dessa kända problem.
Till slut blev XCUI det föredragna valet. Med detta kommer en utvecklare att ha mer kontroll över automatiseringen och kommer att vara den omedelbara mottagaren av alla innovationer i Apples ekosystem.
Applikation under test och XCUI-automatiseringsmodul
Innan vi går in på detaljerna är det viktigt att upprepa att automatiseringsmodulen som använder XCUI körs som en oberoende process från applikationen som är under test. Till att börja med lade vi till en ny modul som vi i fortsättningen kommer att referera till som Automation Module(AM). AM är en arbetsyta som innehåller en samling klasser och datastrukturer som används för automatisering av VMware Boxer med hjälp av XCUI.
Accessibility Identifiers
Det är viktigt att applikationen utvecklas med dess testbarhet i åtanke. Ett av utvecklarens ansvarsområden är att se till att varje element i användargränssnittet som exponeras för slutanvändaren har en tillgänglighetsidentifierare som har ställts in under utvecklingen. Tillgänglighetsidentifieraren är länken mellan den testade applikationen och XCUI-automatiseringsprocessen.
Tillgänglighetsidentifieraren är länken mellan den testade applikationen och XCUI-automatiseringsprocessen.
Designmönster
Som tidigare nämnts är VMware Boxer en enorm applikation. Valet av designmönster som skulle användas gjordes med tanke på att testerna skulle vara lätta att implementera, lätta att underhålla, återanvändbara, robusta och skalbara. Innehållet nedan förklarar skikten i XCUI Automation-modulens arkitektur för VMware Boxer:
Följande figur visar de grundläggande byggstenarna:
Testklasser
Detta är det skikt som har de klasser som har testmetoderna. Avsikten med det här lagret är att testerna ska bestå av minimal kod som bara säger det som ska testas. Dessutom behöver utvecklaren som genomför testerna bara tänka på det högnivåprogramflöde som krävs för att testa det som testas. Resten av komplexiteten (t.ex. hur man navigerar till användargränssnittet där den önskade testningen kan utföras) bör abstraheras till återanvändbara lager. Se bilden nedan som visar ett exempel på en testmetod som förklarar ovanstående avsikt – koden testar om ett användargränssnitt för inställningar kan hjälpa till att aktivera/avaktivera en funktion eller om det har nödvändiga växelkontroller.
Den utvecklare som skriver testerna skulle alltså kunna skriva kod som är så enkel som pseudokod. Samtidigt står det klart att viss logik bör åberopas från nästa lager (Flows : förklaras i nästa avsnitt).
Flows Classes
Flows representerar en samling klasser som tillhandahåller de funktioner som krävs för olika Test-klasser. Funktionaliteterna kan vara att ställa in appen innan det verkliga testfallet utförs eller att navigera till en viss del av appen som testas. De flesta av dessa funktioner kan återanvändas och krävs i flera tester, t.ex. krävs det i testfallet ovan att 1. appen startas och 2. appen startas och 3. appen startas och 4. appen startas. Vi navigerar till en skärm med inställningar för en funktionskontrollant.
Så, flödesklasser skulle anropas från tester och skulle implementera flöden som ”Navigera till inställningar” eller ”Navigera till inställningar för funktionskontrollanter”.
Screens-klasser
Screens är klasser som har en en-till-en-mappning till respektive View Controllers. En View Controller kan, på hög nivå, ses som en klass som har (i backing view) UIControls och metoder som svarar på användarens interaktion med dessa UIControls. En Screen-klass är helt enkelt en proxymappning av View Controller. Figuren nedan visar denna mappning. Det finns en cell Initial View i användargränssnittet och när användaren trycker på denna cell kan användaren välja vad som ska markeras som den initiala vyn för appen. Figuren nedan visar hur en Screen-klass implementeras för att mappa ovanstående krav.
Pseudokoden för denna Screen-klass skulle se ut så här –
// 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"
}
Vad är boxerApp i ovanstående kod? I ovanstående kod representerar boxerApp en enhet som är en instans av BoxerApp-klassen som kapslar in programmet under test och dess skärmar. Detta förklaras i nästa avsnitt.
Koden ovan modellerar SettingFormViewController i VMware Boxer. Den konvention som används för att namnge klassen är att namnet härleds från namnet på view controller genom att ersätta suffixet ViewController med Screen. Notera också bekvämlighetsklassen som har tillgänglighetsidentifierare.
Tillgänglighetsidentifieraren är den gemensamma länken mellan applikationen under test och XCUI-automatiseringsprocessen.
Sätt ihop det: VMware Boxer XCUI Automation Module
UITest-modulen testar det körda programmet. Det är viktigt att applikationsmodellen utformas så att en instans av applikationen som testas är en enda enhet. Detta innebär att den testade applikationen bör ses som en samling skärmklasser som deltar i affärsflöden (samling flödesklasser)som anropas från testerna (samling klasser)baserat på testets krav. Varje applikationsenhet bör ha exakt en instans av varje skärmklass som motsvarar en vykontrollant.
Hur uppnår man detta?
En XCUIT-testsekvens kan uppnå detta genom att kapsla in den testade applikationen (XCUIApplication) i en enhet, t.ex. klassen BoxerApp som har en medlemsapplikation och har alla skärmar för den applikationen. Figuren nedan förklarar denna inkapsling
För att XCUITest-sviten ska kunna starta är det första som den gör att skapa en instans av BoxerApp-modulen med hjälp av bundle-identifieraren för den applikation som ska testas. Figuren nedan förklarar detta
Denna instans av BoxerApp (enheten som kapslar in XCUIApplicationen och skärmarna) skickas sedan av Tests::testMethod till Flows::flowMethod som första parameter.
Flöden::flödesmetoden anropar i sin tur Screen::screenMethod och överlämnar BoxerApp om så krävs.
Slutligt sker interaktionen med applikationens användargränssnitt genom Screen::screenMethod.
Figuren nedan visar ovanstående design.
Slutsats
Att skriva XCUI-tester kan vara besvärligt och svårhanterligt om det inte görs med en plan. Jag hoppas att det här inlägget ger användbara tips om hur man kan tänka på att strukturera sitt automationsprojekt på ett modulärt, rent och skiktat sätt.
Vad händer härnäst?
Jag kommer att täcka dessa ämnen i den serie berättelser som jag planerar:
XCUI : Del 2 -Interaktion med Native-applikationer på ett rent sätt
XCUI : Del 3 -Hur XCUI runtime kan interagera med applikationen under test på ett rent sätt.
XCUI : Del 4 -Hantering av systemvarningar.
XCUI : Del 5 -Observation av testets framskridande och tillgång till rapporter och skärmdumpar.
XCUI : Del 5 -Observation av testets framskridande och tillgång till rapporter och skärmdumpar.