Einen Regressionstest für iOS-Barrierefreiheit auf dem Cloud-Mac einrichten

Schon das Umbenennen einer Schaltfläche, der Austausch eines Symbols oder eine Änderung an den Constraints kann dazu führen, dass auf einem iOS-Bildschirm lesbare Beschriftungen fehlen, Trefferflächen kleiner werden oder Text bei großen Schriftgrößen abgeschnitten wird. Manuelle Prüfungen lassen sich kaum bei jedem Commit vollständig durchführen. Zuverlässiger ist es, den Zustand von Simulator und App auf einem Cloud-Mac festzulegen, die Barrierefreiheitsaudits mit XCTest auszuführen und Fehler in reproduzierbare Merge-Prüfungen zu überführen.

Zuerst den Umfang der Merge-Prüfung festlegen

Durchlaufen Sie nicht gleich zu Beginn das gesamte Produkt. Wählen Sie zunächst häufig genutzte Abläufe aus, etwa den Startbildschirm nach der Anmeldung, die zentrale Bearbeitungsansicht und die Bestätigungsseite nach dem Absenden. Jeder Testfall sollte nur einen stabilen Zustand prüfen. Animationen, zufällige Empfehlungen, die aktuelle Uhrzeit und Netzwerkantworten verändern den Elementbaum. Sie sollten daher im Testmodus deaktiviert oder durch feste Daten ersetzt werden.

Für den ersten Durchlauf empfehlen sich vier Problemkategorien:

Automatisierte Audits erkennen Probleme, die sich maschinell zuverlässig beurteilen lassen. Sie belegen nicht, dass die gesamte Interaktion gut bedienbar ist. Lesereihenfolge, Verständlichkeit von Hinweisen und komplexe Gesten müssen weiterhin manuell geprüft werden.

Einen deterministischen Bildschirmzustand für den Test schaffen

Nichts macht UI-Tests anfälliger als unterschiedliche Ansichten trotz identischem Einstiegspunkt. Die App sollte ausschließlich für Tests vorgesehene Startargumente erkennen, beim Start temporäre Zustände löschen, feste Daten laden und nicht benötigte Animationen deaktivieren. Diese Argumente dürfen nur die Testumgebung verändern und nicht in die produktive Geschäftslogik einfließen.

let app = XCUIApplication()
app.launchArguments = [
    "-ui-testing",
    "-reset-demo-state",
    "-disable-animations"
]
app.launchEnvironment["TEST_LOCALE"] = "zh-Hans"
app.launch()

Die Testdaten sollten innerhalb des App-Prozesses vorbereitet werden, damit der UI-Test nicht von einer Echtzeit-API abhängt. Wenn Ladezustände, leere Datenbestände, Fehler und reguläre Ergebnisse abgedeckt werden sollen, legen Sie für jeden Zustand ein eigenes Argument an. Nach einem Fehler genügt dann das erneute Ausführen des Befehls; auf das Wiederauftreten einer bestimmten externen Bedingung muss nicht gewartet werden.

Elemente stabil identifizieren

Wichtige Steuerelemente sollten weder über den Titel einer Schaltfläche noch über Koordinaten gefunden werden. Titel ändern sich mit der Lokalisierung, Koordinaten mit Fenstergröße und Schriftgröße. Vergeben Sie für interaktive Elemente einen semantisch stabilen accessibilityIdentifier:

checkoutButton.accessibilityIdentifier = "checkout.submit"
cartSummary.accessibilityIdentifier = "checkout.summary"

Der Bezeichner sollte die Aufgabe des Elements beschreiben, nicht seine visuelle Position. Ein Name wie footer.orangeButton verliert nach einer Überarbeitung seine Bedeutung. checkout.submit bleibt dagegen über verschiedene Layouts hinweg verwendbar.

Gezielte XCTest-Audits ausführen

Wenn die verwendete Systemversion die entsprechenden APIs unterstützt, kann das Audit auf einer Ansicht ausgeführt werden, sobald sie einen stabilen Zustand erreicht hat. Warten Sie zunächst auf das zentrale Element und starten Sie erst danach die Prüfung. So wird ein vorübergehendes Layout während des Ladens nicht fälschlich als Fehler gewertet.

func testCheckoutAccessibility() throws {
    let app = XCUIApplication()
    app.launchArguments = ["-ui-testing", "-reset-demo-state"]
    app.launch()

    let submit = app.buttons["checkout.submit"]
    XCTAssertTrue(submit.waitForExistence(timeout: 10))

    if #available(iOS 17.0, *) {
        try app.performAccessibilityAudit(for: [
            .sufficientElementDescription,
            .hitRegion,
            .contrast,
            .textClipped
        ])
    }
}

Erstellen Sie nicht vorschnell eine globale Ausnahmeliste. Ist eine vorübergehende Ausnahme wirklich erforderlich, muss sie auf eine bestimmte Ansicht, eine konkrete Elementkennung und einen klar definierten Problemtyp begrenzt werden. Zusätzlich sollte im Code-Review festgehalten werden, unter welchen Bedingungen die Ausnahme wieder entfernt wird. Andernfalls entwickeln sich solche Einträge schrittweise zu dauerhaften blinden Flecken.

Ausführungsbedingungen auf dem Cloud-Mac festschreiben

Prüfen Sie zuerst, welche Simulatorgeräte und Runtimes aktuell verfügbar sind. Anschließend übergibt die Pipeline eine eindeutig festgelegte Destination. Gehen Sie nicht davon aus, dass auf jedem Knoten bereits ein gleichnamiges Gerät vorhanden ist.

xcrun simctl list devices available
xcrun simctl list runtimes

export SIM_DESTINATION='platform=iOS Simulator,name=iPhone 15,OS=17.5'

set -o pipefail
xcodebuild test \
  -project ExampleApp.xcodeproj \
  -scheme ExampleAppUITests \
  -destination "$SIM_DESTINATION" \
  -only-testing:ExampleAppUITests/AccessibilityTests \
  -resultBundlePath "$PWD/TestResults/Accessibility.xcresult"

In der tatsächlichen Ausführung sollten Gerätename und Systemversion als Pipeline-Variablen definiert werden und zu den auf dem Knoten installierten Runtimes passen. Erstellen Sie vor dem Lauf einen neuen Simulator. Wird ein Gerät wiederverwendet, müssen zuvor die App beendet und der Testzustand bereinigt werden. Parallele Jobs dürfen nicht denselben Simulator nutzen, da sich sonst Spracheinstellungen, Berechtigungsdialoge und Restzustände vorheriger Testfälle gegenseitig beeinflussen.

Das Modell des Cloud-Mac und die Wahl des Knotens ändern nichts an den Grundsätzen des Testdesigns. Wenn eine weitere Ausführungsumgebung benötigt wird, prüfen Sie in der Konsole die aktuell verfügbaren Konfigurationen. Dokumentieren Sie außerdem Xcode-Version, Runtime-Version, Sprache und Destination, damit sich ein Fehler unter denselben Bedingungen erneut ausführen lässt.

Tests abstufen und häufige Fehlalarme untersuchen

Führen Sie für jeden Merge Request nur die wichtigsten Ansichten, die Standardsprache und eine reguläre Schriftgröße aus, damit die Rückmeldezeit für das Team akzeptabel bleibt. Auf dem Hauptbranch kann die Abdeckung anschließend um mehrere Sprachen, Hoch- und Querformat, dunkles Erscheinungsbild und dynamische Schriftgrößen erweitert werden. Packen Sie nicht alle Kombinationen in eine einzige Testmethode. Werden Tests nach Ansicht und Zustand getrennt, lässt bereits der Fehlername den betroffenen Umfang erkennen.

Gehen Sie bei instabilen Fehlern in dieser Reihenfolge vor:

1. Prüfen Sie, ob das zentrale Element vollständig geladen wurde und nicht nur im Elementbaum vorhanden ist.
2. Vergleichen Sie die Einstellungen für Sprache, Region, Schriftgröße, Ausrichtung und Erscheinungsbild.
3. Prüfen Sie, ob die Testdaten durch den vorherigen Lauf verändert wurden.
4. Führen Sie nur die fehlgeschlagene Methode erneut aus und prüfen Sie, ob sich das Problem zuverlässig reproduzieren lässt.
5. Speichern Sie das Testergebnispaket, den ausgeführten Befehl und die Umgebungsparameter. Entscheiden Sie anschließend, ob ein Produktfehler oder eine unzureichende Testisolation vorliegt.

Auch die Regeln der Merge-Prüfung sollten abgestuft sein. Fehlende Beschreibungen, nicht bedienbare Trefferflächen und überlappender Text sollten einen Merge blockieren. Kontrastprobleme, deren Designprüfung noch aussteht, können zunächst dokumentiert werden, benötigen aber eine verantwortliche Person und eine verbindliche Frist. Das Ziel ist nicht ein Bericht, der dauerhaft vollständig grün bleibt. Jeder Fehler soll sich vielmehr eindeutig einer Ansicht, einem Zustand, einem Element und konkreten Umgebungsbedingungen zuordnen lassen.

Häufig gestellte Fragen