Seit Apple das XCUI-Framework eingeführt hat, ist die Automatisierung von UI-Tests auf iOS so einfach wie das Schreiben von Unit-Tests geworden. In diesem Beitrag werde ich darüber sprechen, wie XCUI in Verbindung mit einem mehrschichtigen Design dazu beitragen kann, Anwendungen zu automatisieren, insbesondere solche mit mehreren angepassten UI-Elementen. Eine solche Anwendung, bei der wir dies ausgiebig genutzt haben, ist VMware Boxer, eine Unternehmensanwendung von VMware, die drei wichtige Funktionen zusammenfasst – E-Mail, Kalender und Kontakte. VMware Boxer verwendet mehrere Arten von UI-Elementen, von der nativen UITableView bis hin zu hochgradig angepassten visuellen Elementen.
Es wird vorausgesetzt, dass die Leser ein grundlegendes Verständnis von Xcode, Objective C, Swift, dem XCUI-Framework und dem Apple-Entwicklungsökosystem im Allgemeinen haben. Wenn Sie neu in XCUI sind, sollten Sie hier beginnen.
Wie jedes andere UI-Automatisierungsprojekt begann unser Team mit der Frage, welches Automatisierungsframework wir verwenden sollten. Wir hatten SeeTest verwendet. Angesichts der neuen, komplexen Funktionen von VMware Boxer, der Anzahl der Produkte im VMware-Ökosystem und der Integrationstests für diese Produkte sahen wir dies jedoch als Gelegenheit, unsere Automatisierungsstrategie zu überprüfen. Im Folgenden sind die Optionen aufgeführt, die wir in Betracht gezogen haben –
1. Weiter mit SeeTest
2. Earl Grey
3. XCUI
Während SeeTest unsere unmittelbaren Anforderungen an die Automatisierung erfüllen konnte, gab es eine weitere Herausforderung zu bewältigen. Wir mussten ein neues Technologiepaket einführen. Dies würde zusätzliche Schulungen für iOS-Entwickler und spezielle Experten für die Wartung des Automatisierungssystems erfordern.
Was ist mit Appium? Wir haben Appium aus denselben Gründen, die oben für SeeTest genannt wurden, nicht in Betracht gezogen. Appium ist eine gute Wahl, wenn wir hybride Apps oder signifikanten gemeinsamen Code zwischen Android und iOS haben.
Earl Grey 1 war eine mögliche Wahl, da es uns erlaubte, in Xcode und den Apple-Entwicklungstools zu bleiben und es auf XCTest basierte. Die Automatisierung von Earl Grey 1 läuft jedoch im selben Prozess wie die zu testende Anwendung. Die auf dem XCUI-Framework von Apple basierende Automatisierung läuft dagegen in einem anderen Prozess als die zu testende Anwendung. Dies ist vorzuziehen, da die zu testende Anwendung nicht mehr als eine Blackbox für die Entität (ein Automatisierungsprozess oder ein Endbenutzer) sein sollte, die ihre Benutzeroberfläche testet.
Der Automatisierungsprozess (derjenige, der testet) sollte von der eigentlichen zu testenden Anwendung isoliert sein. Die zu testende Anwendung sollte nicht mehr als eine Blackbox für den Automatisierungsprozess sein.
Jedes neue Tool im Apple-Ökosystem, das nicht mit Apples Ansatz übereinstimmt (z.B. Earl Grey 1), kann ohne Vorwarnung fehlschlagen. Ein solcher Ansatz kann einen hohen Wartungsaufwand erfordern, um weiterhin mit neueren oder zukünftigen Angeboten von Apple zusammenzuarbeiten.
Early Grey 2 fügte die Fähigkeit hinzu, mit XCUI zu interagieren. Es war ein Versuch, sich an XCUI anzugleichen, aber es hatte diese bekannten Probleme.
Letztendlich war XCUI die bevorzugte Wahl. Damit hat ein Entwickler mehr Kontrolle über die Automatisierung und ist der unmittelbare Nutznießer jeder Innovation im Apple-Ökosystem.
Die zu testende Anwendung und das XCUI-Automatisierungsmodul
Bevor wir uns in die Details stürzen, ist es wichtig zu wiederholen, dass das Automatisierungsmodul mit XCUI als unabhängiger Prozess von der zu testenden Anwendung läuft. Zu Beginn haben wir ein neues Modul hinzugefügt, das wir von nun an als Automatisierungsmodul (AM) bezeichnen werden. AM ist ein Arbeitsbereich, der eine Sammlung von Klassen und Datenstrukturen enthält, die für die VMware Boxer-Automatisierung mit XCUI verwendet werden.
Zugänglichkeitskennungen
Es ist wichtig, dass die Anwendung unter Berücksichtigung ihrer Testbarkeit entwickelt wird. Eine der Verantwortlichkeiten des Entwicklers ist es, sicherzustellen, dass jedes Element der Benutzeroberfläche, das dem Endbenutzer zugänglich ist, während der Entwicklung mit einem Accessibility Identifier versehen wird. Der Accessibility Identifier ist das Bindeglied zwischen der zu testenden Anwendung und dem XCUI-Automatisierungsprozess.
Der Accessibility Identifier ist das Bindeglied zwischen der zu testenden Anwendung und dem XCUI-Automatisierungsprozess.
Design Pattern
Wie bereits erwähnt, ist VMware Boxer eine umfangreiche Anwendung. Bei der Wahl des zu verwendenden Entwurfsmusters wurde berücksichtigt, dass die Tests einfach zu implementieren, einfach zu warten, wiederverwendbar, robust und skalierbar sein sollten. Der folgende Inhalt erklärt die Schichten der Architektur des XCUI-Automatisierungsmoduls für VMware Boxer:
Die folgende Abbildung zeigt die grundlegenden Bausteine:
Tests Klassen
Dies ist die Schicht, die die Klassen mit den Testmethoden enthält. Das Ziel dieser Schicht ist es, dass die Tests aus minimalem Code bestehen, der nur sagt, was getestet wird. Außerdem muss der Entwickler, der die Tests implementiert, nur über den High-Level-Anwendungsablauf nachdenken, der zum Testen des Getesteten erforderlich ist. Der Rest der Komplexität (z. B. wie man zur Benutzeroberfläche navigiert, auf der die gewünschten Tests durchgeführt werden können) sollte auf wiederverwendbare Schichten abstrahiert werden. Die folgende Abbildung zeigt ein Beispiel für eine Testmethode, die die obige Absicht erklärt – der Code testet, ob eine Einstellungs-UI beim Aktivieren/Deaktivieren einer Funktion helfen kann oder ob sie die erforderlichen Schaltkontrollen hat.
Der Entwickler, der die Tests schreibt, könnte also Code schreiben, der so einfach wie Pseudocode ist. In der Zwischenzeit ist es klar, dass eine gewisse Logik von der nächsten Schicht (Flows: wird im nächsten Abschnitt erklärt) aufgerufen werden sollte.
Flows Classes
Flows stellen eine Sammlung von Klassen dar, die Funktionalitäten bereitstellen, die für verschiedene Testklassen erforderlich sind. Zu den Funktionalitäten gehören beispielsweise das Einrichten der App vor der Ausführung des eigentlichen Testfalls oder das Navigieren zu einem bestimmten Teil der zu testenden App. Die meisten dieser Funktionalitäten sind wiederverwendbar und werden in mehreren Tests benötigt. z.B. erfordert der obige Beispiel-Testfall, dass 1. die App gestartet wird und 2. Wir navigieren zu einem Feature-Controller-Einstellungsbildschirm.
So würden Flow-Klassen von Tests aufgerufen werden und Flows wie „Navigiere zu Einstellungen“ oder „Navigiere zu Feature-Controller-Einstellungen“ implementieren.
Screens-Klassen
Screens sind Klassen, die eine Eins-zu-Eins-Zuordnung zu entsprechenden View-Controllern haben. Ein View-Controller kann auf hohem Niveau als eine Klasse gesehen werden, die (in der Backing-View) UIControls und Methoden hat, die auf Benutzerinteraktion mit diesen UIControls reagieren. Eine Screen-Klasse ist einfach eine Proxy-Abbildung des View-Controllers. Die Abbildung unten zeigt diese Abbildung. Es gibt eine Zelle Initial View in der UI und wenn der Benutzer auf diese Zelle tippt, kann er auswählen, was als Initial View für die App markiert werden soll. Die folgende Abbildung zeigt, wie eine Screen-Klasse implementiert wird, um die obige Anforderung abzubilden.
Der Pseudocode für diese Screen-Klasse würde wie folgt aussehen –
// 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"
}
Was ist boxerApp im obigen Code? Im obigen Code stellt boxerApp eine Einheit dar, die eine Instanz der Klasse BoxerApp ist, die die zu testende Anwendung und ihre Bildschirme kapselt. Dies wird im nächsten Abschnitt erläutert.
Der obige Code modelliert den SettingFormViewController von VMware Boxer. Die Konvention, die bei der Benennung der Klasse verwendet wird, ist, dass der Name vom Namen des View-Controllers abgeleitet wird, indem das Suffix ViewController durch Screen ersetzt wird. Beachten Sie auch die Convenience-Klasse, die Zugänglichkeitsbezeichner hat.
Der Zugänglichkeitsbezeichner ist das gemeinsame Bindeglied zwischen der zu testenden Anwendung und dem XCUI-Automatisierungsprozess.
Putting it Together: VMware Boxer XCUI Automation Module
Das UITest-Modul testet die laufende Anwendung. Es ist wichtig, dass das Anwendungsmodell so gestaltet ist, dass eine Instanz der zu testenden Anwendung eine einzelne Einheit darstellt. Das bedeutet, dass die zu testende Anwendung als eine Sammlung von Bildschirmklassen betrachtet werden sollte, die an Geschäftsabläufen (Sammlung von Ablaufklassen) beteiligt sind, die von den Tests (Sammlung von Klassen) auf der Grundlage der Testanforderungen aufgerufen werden. Jede Anwendungseinheit sollte genau eine Instanz jeder Screen-Klasse haben, die einem View-Controller entspricht.
Wie kann dies erreicht werden?
Eine XCUITest-Suite kann dies erreichen, indem sie die zu testende Anwendung (XCUIApplication) in einer Einheit kapselt, z.B. die Klasse BoxerApp, die eine Mitgliedsanwendung hat und alle Screens für diese Anwendung enthält. Die nachstehende Abbildung erläutert diese Kapselung
Daher wird vor dem Start der XCUITest-Suite zunächst eine Instanz des BoxerApp-Moduls unter Verwendung der Bündelkennung der zu testenden Anwendung erstellt. Die folgende Abbildung erläutert dies
Diese Instanz von BoxerApp (die Einheit, die die XCUIApplication und Screens kapselt) wird dann von der Tests::testMethod an Flows::flowMethod als erster Parameter übergeben.
Die Flows::flowMethod ruft ihrerseits Screen::screenMethod auf und übergibt BoxerApp, falls erforderlich.
Schließlich erfolgt die Interaktion mit der Benutzeroberfläche der Anwendung über Screen::screenMethod.
Die folgende Abbildung zeigt das obige Design.
Schlussfolgerung
Das Schreiben von XCUI-Tests kann mühsam und unüberschaubar sein, wenn es nicht mit einem Plan gemacht wird. Ich hoffe, dass dieser Beitrag hilfreiche Hinweise gibt, wie Sie Ihr Automatisierungsprojekt modular, sauber und schichtweise strukturieren können.
Wie geht es weiter?
Ich werde diese Themen in einer Serie von Beiträgen behandeln, die ich plane:
XCUI : Teil 2 – Interaktion mit nativen Anwendungen auf eine saubere Art
XCUI : Teil 3 -Wie die XCUI-Laufzeit mit der zu testenden Anwendung auf eine saubere Art interagieren kann.
XCUI : Teil 4 -Verarbeitung von Systemwarnungen.
XCUI : Teil 5 -Überwachung des Testfortschritts, Zugriff auf Berichte und Erfassung von Screenshots.