Het automatiseren van UI-tests op iOS is net zo eenvoudig geworden als het schrijven van unit tests sinds Apple het XCUI-framework heeft geïntroduceerd. In dit bericht ga ik het hebben over hoe XCUI, in combinatie met gelaagd ontwerp, kan helpen bij het eenvoudig automatiseren van applicaties, vooral die met meerdere aangepaste UI-elementen. Een dergelijke applicatie waar we dit uitgebreid hebben gebruikt is VMware Boxer, een enterprise applicatie van VMware die drie belangrijke functies samenvoegt – Email, Calendar en Contacts. VMware Boxer maakt gebruik van meerdere soorten UI-elementen, van native UITableView tot sterk aangepaste visuele elementen.
Het wordt verondersteld dat lezers een basiskennis hebben van Xcode, Objective C, Swift, XCUI framework en het Apple development ecosysteem in het algemeen. Als XCUI nieuw voor u is, moet u eerst hier beginnen.
Net als elk ander UI-automatiseringsproject begon ons team met een vraag over welk automatiseringsraamwerk te gebruiken. We hadden SeeTest gebruikt. We zagen dit echter als een kans om onze automatiseringsstrategie te herzien, gezien de nieuwe, complexe functionaliteit die is toegevoegd in VMware Boxer, het aantal producten in het VMware-ecosysteem en het testen van de integratie tussen deze producten. Hieronder waren de keuzes die we overwogen-
1. Doorgaan met SeeTest
2. Earl Grey
3. XCUI
Terwijl SeeTest de capaciteit had om te voldoen aan onze onmiddellijke behoeften om te automatiseren, was er een onafhankelijke uitdaging om mee om te gaan. Het vereiste van ons om een nieuwe technologie stack te adopteren. Dit zou extra training voor iOS-ontwikkelaars en speciale experts voor het onderhoud van het automatiseringssysteem vereisen.
Hoe zit het met Appium? We hebben Appium niet overwogen om dezelfde redenen die hierboven voor SeeTest zijn genoemd. Appium is een goede keuze als we hybride apps hadden of significante gedeelde code tussen Android en iOS.
Earl Grey 1 was een mogelijke keuze, aangezien we hiermee in Xcode en Apple-ontwikkeltools konden blijven en het was gebaseerd op XCTest. De Earl Grey 1-automatisering draait echter in hetzelfde proces als de te testen applicatie. Aan de andere kant, Apple’s XCUI framework-gebaseerde automatisering draait in een apart proces dan de applicatie die getest wordt. Dit heeft de voorkeur omdat de te testen applicatie niets meer dan een zwarte doos zou moeten zijn voor de entiteit (een automatiseringsproces of een eindgebruiker) die de UI ervan test.
Houd het automatiseringsproces (een proces dat test) geïsoleerd van de feitelijke te testen applicatie. De te testen applicatie mag niet meer zijn dan een zwarte doos voor het automatiseringsproces.
Elk nieuw hulpmiddel in het Apple-ecosysteem dat niet op één lijn ligt met de aanpak van Apple (bijv. Earl Grey 1) kan zonder waarschuwing mislukken. Een dergelijke aanpak kan veel onderhoud vergen om te kunnen blijven werken met nieuwere of toekomstige aanbiedingen van Apple.
Early Grey 2 voegde de mogelijkheid toe om te communiceren met XCUI. Het was een poging om aan te sluiten bij XCUI, maar het had de bekende problemen.
Uiteindelijk kreeg XCUI de voorkeur. Hiermee heeft een ontwikkelaar meer controle over de automatisering en profiteert hij direct van alle innovaties in het ecosysteem van Apple.
App onder test en automatiseringsmodule XCUI
Voordat we in detail treden, is het belangrijk om te herhalen dat de automatiseringsmodule met XCUI als een onafhankelijk proces van de te testen applicatie wordt uitgevoerd. Om te beginnen hebben we een nieuwe module toegevoegd waarnaar we vanaf nu zullen verwijzen als de Automatiseringsmodule (AM). AM is een werkruimte die een verzameling van klassen en gegevensstructuren bevat die worden gebruikt voor VMware Boxer automatisering met behulp van XCUI.
Accessibility Identifiers
Het is belangrijk dat de applicatie wordt ontwikkeld met de testbaarheid ervan in gedachten. Een van de verantwoordelijkheden van de ontwikkelaar is ervoor te zorgen dat voor elk gebruikersinterface-element dat aan de eindgebruiker wordt blootgesteld, tijdens de ontwikkeling de toegankelijkheids-identifier wordt ingesteld. De toegankelijkheidsidentifier vormt de schakel tussen de te testen applicatie en het automatiseringsproces XCUI.
De toegankelijkheidsidentifier vormt de schakel tussen de te testen applicatie en het automatiseringsproces XCUI.
Ontwerppatroon
Zoals eerder vermeld, is VMware Boxer een enorme applicatie. Bij de keuze van het te gebruiken ontwerppatroon is er rekening mee gehouden dat de tests eenvoudig te implementeren, eenvoudig te onderhouden, herbruikbaar, robuust en schaalbaar moeten zijn. In de onderstaande inhoud worden de lagen van de architectuur van de XCUI Automatiseringsmodule voor VMware Boxer toegelicht:
De volgende figuur toont de basisbouwstenen:
Tests Classes
Dit is de laag die de klassen bevat die de testmethoden bevatten. De bedoeling van deze laag is dat de tests uit minimale code bestaan die alleen zegt wat er getest wordt. Ook hoeft de ontwikkelaar die de tests uitvoert alleen maar na te denken over de high-level applicatie flow die nodig is om te testen wat er getest wordt. De rest van de complexiteit (b.v. hoe te navigeren naar de UI waar de gewenste test kan worden uitgevoerd) moet worden geabstraheerd naar herbruikbare lagen. Zie de afbeelding hieronder die een voorbeeld test methode laat zien die de bovenstaande bedoeling uitlegt – de code test of een Instellingen UI kan helpen bij het in-/uitschakelen van een functie en of het de benodigde schakelbedieningen heeft.
De ontwikkelaar die de tests schrijft, zou dus code kunnen schrijven die zo eenvoudig is als pseudo-code. In de tussentijd is het duidelijk dat sommige logica moet worden opgeroepen vanuit de volgende laag (Flows: uitgelegd in de volgende sectie).
Flows Klassen
Flows vertegenwoordigen een verzameling klassen die functionaliteiten bieden die nodig zijn voor verschillende Tests klassen. Functionaliteiten kunnen zijn het opzetten van de app voordat de echte test case wordt uitgevoerd of het navigeren naar een bepaald deel van de app die wordt getest. De meeste van deze functionaliteiten zijn herbruikbaar en vereist in meerdere tests. b.v. de bovenstaande voorbeeld test case vereist dat 1. de app wordt gestart. en 2. We navigeren naar een Feature Controller instellingen scherm.
Dus, Flow klassen zouden worden aangeroepen vanuit Tests en zouden flows implementeren als “Navigeer naar Instellingen” of “Navigeer naar Feature Controller Instellingen”.
Schermen Klassen
Schermen zijn klassen die een één-op-één mapping hebben naar respectievelijke View Controllers. Een View Controller kan op hoog niveau worden gezien als een klasse die (in de backing view) UIControls heeft en methoden die reageren op gebruikersinteractie met die UIControls. Een schermklasse is eenvoudigweg een proxy mapping van de View Controller. De figuur hieronder toont deze mapping. Er is een cel Initial View in de UI en wanneer de gebruiker op deze cel tikt, kan de gebruiker kiezen wat moet worden gemarkeerd als de initiële view voor de app. De onderstaande figuur laat zien hoe een Screen class is geïmplementeerd om de bovenstaande eis in kaart te brengen.
De pseudo code voor deze screen class zou er als volgt uitzien –
// 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"
}
wat is boxerApp in bovenstaande code? In bovenstaande code vertegenwoordigt boxerApp een unit die een instantie is van de BoxerApp class die de te testen applicatie en zijn schermen inkapselt. Dit wordt uitgelegd in de volgende sectie.
De bovenstaande code modelleert de SettingFormViewController van VMware Boxer. Bij de naamgeving van de klasse is de conventie gevolgd dat de naam is afgeleid van de naam van de view controller door het achtervoegsel ViewController te vervangen door Screen. Let ook op de gemaksklasse die toegankelijkheids-id’s heeft.
De toegankelijkheids-id is de gemeenschappelijke link tussen de te testen toepassing en het XCUI-automatiseringsproces.
Putting it Together: VMware Boxer XCUI Automation Module
De UITest-module test de draaiende applicatie. Het is belangrijk dat het applicatiemodel zodanig is ontworpen dat een instantie van de te testen applicatie een enkele eenheid is. Dit betekent dat de te testen applicatie moet worden gezien als een verzameling schermklassen die deelnemen aan business flows (verzameling flow classes) die worden aangeroepen vanuit de tests (verzameling classes) op basis van de eis van de test. Elke toepassing eenheid moet precies een instantie van elk scherm klasse die overeenkomt met een view controller.
Hoe dit te bereiken?
Een XCUITest suite kan dit bereiken door inkapseling van de toepassing te testen instantie (XCUIApplication) in een eenheid, bijvoorbeeld BoxerApp klasse die een lid applicatie heeft en heeft alle schermen voor die toepassing. De onderstaande figuur legt deze inkapseling uit
Dus voordat de XCUITest suite start, is het eerste wat deze zou doen het creëren van een instantie van de BoxerApp module met behulp van de bundel identifier van de te testen applicatie. De onderstaande figuur legt dit uit
Deze instantie van BoxerApp (de eenheid die de XCUIApplication en Screens inkapselt) wordt vervolgens door de Tests::testMethod doorgegeven aan Flows::flowMethod als eerste parameter.
De Flows::flowMethod roept op zijn beurt Screen::screenMethod aan en geeft indien nodig BoxerApp door.
De interactie met de UI van de toepassing verloopt ten slotte via Screen::screenMethod.
De onderstaande figuur toont het bovenstaande ontwerp.
Conclusie
Het schrijven van XCUI-tests kan omslachtig en onhandelbaar zijn als het niet met een plan wordt gedaan. Ik hoop dat dit bericht nuttige aanwijzingen geeft over hoe je je automatiseringsproject op een modulaire, schone, gelaagde manier kunt structureren.
Wat is het volgende?
Ik ga deze onderwerpen behandelen in de serie verhalen die ik aan het plannen ben:
XCUI : Deel 2 -Interactie met Native applicaties op een schone manier
XCUI : Deel 3 -Hoe XCUI runtime kan interageren met de applicatie onder test op een schone manier.
XCUI : Deel 4 -Handling System Alerts.
XCUI : Deel 5 -Observatie van de voortgang van de test en de toegang tot rapporten en het vastleggen van Screenshots.