XCUITest: Was es ist, Funktionsweise und iOS-UI-Tests

Was ist XCUITest

XCUITest ist ein UI-Test-Framework, das von Apple in Xcode 7 (2015) veröffentlicht wurde. Es löste UI Automation (UIA) ab und wurde zum Standardwerkzeug für automatisierte Oberflächentests auf Apple-Plattformen. XCUITest ist vollständig in XCTest integriert – Apples einheitliches Test-Framework.

Unterschied zu XCTest-Komponententests

Im Gegensatz zu Komponententests, die die Logik auf Klassen- und Methodenebene überprüfen, testet XCUITest die Benutzeroberfläche durch Aktionssimulation. Die Tests werden in einem separaten Prozess von der Anwendung ausgeführt und interagieren über die Accessibility-API mit ihr – dies gewährleistet Isolation und Zuverlässigkeit.

Vorteile des nativen Ansatzes

XCUITest erfordert keine Installation von Drittanbieter-Servern (im Gegensatz zu Appium) oder zusätzlichen Bibliotheken für die Geräteinteraktion. Alles Notwendige ist bereits in Xcode enthalten. Dies gewährleistet die beste Kompatibilität mit neuen iOS-Versionen und sofortigen Zugriff auf neue Gesten und Steuerelemente.

Architektur von XCUITest und XCTest

Die XCUITest-Architektur basiert auf zwei Schlüsselklassen: XCUIApplication – die gestartete testbare Anwendung, und XCUIElement – das Oberflächenelement. Der XCTest-Test-Runner verwaltet den Testlebenszyklus: setUp, Testmethoden, tearDown. XCUITest läuft als separater Prozess, der die Anwendung über die Accessibility-Brücke steuert.

Elementhierarchie

Jedes UI-Element wird durch ein XCUIElement-Objekt repräsentiert, das Methoden zum Abfragen des Zustands (exists, isHittable, label, value) und Aktionen (tap, pressForDuration, swipeUp, typeText) enthält. Elemente werden über Abfrageketten in einer Hierarchie organisiert: app.buttons[].staticTexts[].tables[]. Dies ermöglicht das flexible Auffinden jedes Elements auf dem Bildschirm.

Barrierefreiheit und Lokalisatoren

XCUITest verwendet Accessibility-Attribute zur Identifizierung von Elementen: accessibilityIdentifier – ein programmatischer Identifikator, und accessibilityLabel – eine Beschreibung für VoiceOver. Es wird empfohlen, accessibilityIdentifier im Anwendungscode zu setzen – dies macht die Tests unabhängig von Lokalisierung und Layout stabil.

UI-Tests mit XCUITest schreiben

XCUITest-Tests werden in Swift unter Verwendung der XCTest-Syntax geschrieben. Jede Testklasse erbt von XCTestCase und enthält Methoden, die mit test beginnen. In der setUp-Methode wird die Anwendung mit der erforderlichen Konfiguration gestartet, und in tearDown werden Bereinigung und Sitzungsbeendigung durchgeführt.

Basis-Testszenario

Ein typischer Test: Element finden → Aktion ausführen → Ergebnis überprüfen. Die Elementsuche erfolgt über untergeordnete XCUIElementQuery-Abfragen: app.buttons["loginButton"], app.textFields["email"]. Aktionen: .tap(), .typeText("text"), .swipeUp(). Überprüfungen: XCTAssertTrue(element.exists) oder XCTAssertEqual(element.label, "expected").

import XCTest

class LoginTests: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLoginWithValidCredentials() {
        let emailField = app.textFields["emailInput"]
        emailField.tap()
        emailField.typeText("user@test.com")

        let passwordField = app.secureTextFields["passwordInput"]
        passwordField.tap()
        passwordField.typeText("password123")

        app.buttons["loginButton"].tap()

        let homeLabel = app.staticTexts["homeTitle"]
        XCTAssertTrue(homeLabel.exists)
    }
}

Erwartungen und Synchronisation

XCUITest unterstützt explizite Erwartungen über XCTWaiter und NSPredicate-Prädikate. Zum Beispiel das Warten auf das Erscheinen eines Elements innerhalb von 5 Sekunden: XCTWaiter().wait(for: [expectation], timeout: 5). Im Gegensatz zu Detox hat XCUITest keine automatische Synchronisation mit Netzwerkanfragen.

// Warten auf das Erscheinen des Elements mit Zeitüberschreitung
let expectedElement = app.staticTexts["welcomeMessage"]
let existsPredicate = NSPredicate(format: "exists == true")
let expectation = XCTNSNotificationExpectation(object: expectedElement)
let result = XCTWaiter().wait(
    for: [expectation], timeout: 5
)
XCTAssertEqual(result, .completed)

Erweiterte Funktionen von XCUITest

XCUITest unterstützt das Testen komplexer Szenarien: Multi-Touch-Gesten, Push-Benachrichtigungen, Deep Links, SFSafariViewController und anwendungsübergreifende Interaktion. Siri-Intents können ebenfalls über XCUITest mit Siri-Remote-Simulation getestet werden.

Gestentests

XCUITest unterstützt alle gängigen Gesten: tap, doubleTap, pressForDuration, swipeUp/Down/Left/Right, pinch, rotate, twoFingerTap. Für komplexe Szenarien wird XCUIGesture mit benutzerdefinierten Koordinaten und Dauer verwendet. Dies ermöglicht das Testen benutzerdefinierter Gesten wie Zeichnen oder Drag-and-Drop.

Netzwerkanfragen abfangen

Ab Xcode 12 unterstützt XCUITest das Abfangen von Netzwerkanfragen über XCTestExpectation und URLProtocol. Dies ermöglicht das Testen der Anwendung im Offline-Modus oder mit simulierten Serverantworten ohne Änderung des Anwendungscodes.

XCUITest in CI/CD

XCUITest wird in CI-Umgebungen über xcodebuild mit dem test-Flag ausgeführt. Für die parallele Ausführung auf mehreren Simulatoren wird xcodebuild -testPlan mit paralleler Ausführungskonfiguration im Xcode-Schema verwendet. GitHub Actions, Bitrise und Jenkins haben integrierte Unterstützung für XCUITest.

Konfiguration für CI

Für CI müssen Code-Signing, Provisioning-Profile und das Ziel (Simulator oder Gerät) konfiguriert werden. iOS-Tests auf dem Simulator benötigen keine Zertifikate. Für echte Geräte ist automatisches Signieren über Xcode Cloud oder Fastlane erforderlich.

# XCUITest auf dem Simulator über xcodebuild ausführen
xcodebuild test \
  -project MyApp.xcodeproj \
  -scheme MyApp \
  -destination 'platform=iOS Simulator,name=iPhone 15,OS=17.5' \
  -resultBundlePath ./TestResults \
  -parallel-testing-enabled YES \
  -parallel-testing-worker-count 4

Barrierefreiheitstests mit XCUITest

XCUITest ist eng mit der Accessibility-API von Apple verbunden, da die Elementsuche auf Accessibility-Attributen basiert. Barrierefreiheitstests sind nicht nur eine Möglichkeit, Elemente zu finden, sondern auch, die Zugänglichkeit der Anwendung für Menschen mit Behinderungen zu überprüfen. XCUITest kann accessibilityLabel, traits und hints überprüfen.

VoiceOver-Überprüfung

VoiceOver ist Apples Bildschirmlesegerät für sehbehinderte Benutzer. XCUITest ermöglicht die Überprüfung von: accessibilityLabel – ob das Element mit klarem Text beschrieben ist, accessibilityTraits – ob der Elementtyp korrekt ist (Schaltfläche, Überschrift, Bild), und accessibilityHint – ob es einen Hinweis zum Aktionsergebnis gibt. Diese Prüfungen sind für die App Store-Veröffentlichung obligatorisch, und XCUITest automatisiert sie im Rahmen von Regressionstests.

Automatische Barrierefreiheitsprüfung

Ab Xcode 15 unterstützt XCUITest die integrierte Barrierefreiheitsprüfung über XCTAttachment mit dem Typ accessibilityAudit. Der Test meldet automatisch Elemente mit unzureichendem Kontrast, unbeschriftete Bilder und falsche Traits. Dies ersetzt den manuellen Accessibility Inspector.

// Barrierefreiheitsaudit in XCUITest
func testAccessibilityAudit() {
    let app = XCUIApplication()
    app.launch()

    let audit = XCTAttachment(accessibilityAudit: app)
    add(audit)

    // Überprüfen eines bestimmten Elements
    let button = app.buttons["submitButton"]
    XCTAssertTrue(button.label.count > 0)
    XCTAssertTrue(button.isAccessibilityElement)
}

Leistungstests in XCUITest

XCUITest unterstützt die Messung der UI-Leistung über XCTOSSignpostMetric und XCUIApplication.metrics. Gemessen werden können die Startzeit der Anwendung, die Navigationsgeschwindigkeit und die Reaktionszeit auf Gesten. Leistungstests werden mit Basislinienmessung ausgeführt und schlagen automatisch fehl, wenn der Schwellenwert überschritten wird. Dies hilft, Leistungseinbußen zu verhindern, bevor sie die Benutzer in einer Release-Version erreichen.

Basislinienkonfiguration

Die Basislinie (Baseline) ist die Referenzausführungszeit eines Tests. Xcode merkt sich die Basislinie für jeden Test auf einem bestimmten Gerätemodell und einer iOS-Version. Wenn eine neue Ausführung die Basislinie um einen bestimmten Prozentsatz (Standard 10%) überschreitet, gilt der Test als fehlgeschlagen. Zum Aktualisieren der Basislinie wird der Befehl Edit Baseline im Testbericht verwendet. Es ist wichtig, die Basislinie bei der Aktualisierung der iOS-Version oder beim Ändern des Gerätemodells für die CI-Farm neu zu berechnen.

Überwachung der Teststabilität

Zur Überwachung der Stabilität von XCUITest-Tests werden Flags verwendet: continueAfterFailure (ob der Test nach dem ersten Fehler fortgesetzt werden soll) und Xcode-Testpläne mit Wiederholungskonfigurationen. Es wird empfohlen, den automatischen Neustart fehlgeschlagener Tests (Retry) zu konfigurieren – bis zu 3 Versuche für instabile Tests im Zusammenhang mit Animations-Timing oder Netzwerkverzögerungen.

Testen von Push-Benachrichtigungen und Deep Links

XCUITest unterstützt das Testen von Push-Benachrichtigungen und Deep Links über springboard und launchArguments. Für Push-Benachrichtigungen wird XCUIApplication().launchArguments mit dem Parameter -UNUserNotificationCenter und dem Senden über XCTest verwendet. Deep Links werden über open URL mit einem benutzerdefinierten Schema getestet – XCUITest fängt den Systemdialog ab und prüft, ob die Anwendung mit dem richtigen Bildschirm geöffnet wurde. Zum Testen des Benachrichtigungsantwort-Szenarios wird XCUIApplication().springboard verwendet, das das Tippen auf das Benachrichtigungsbanner im iOS-Benachrichtigungszentrum simuliert. Diese Szenarien sind kritisch für Anwendungen mit Deep Links und Push-Kampagnen, bei denen die korrekte Behandlung externer Aufrufe überprüft werden muss.

Integration mit Instruments

Für detaillierte Leistungsprofilierung integriert sich XCUITest mit Instruments. Während des Tests kann die Profilerstellung von Time Profiler, Core Animation oder Leaks über XCTMetric gestartet werden. Die Profilerstellungsergebnisse werden im Bericht gespeichert und sind zur Analyse in Xcode verfügbar. Dies ist besonders nützlich für die Optimierung der Anwendungsstartzeit, der Navigation zwischen Bildschirmen und der Animationsleistung – typische Engpässe in iOS-Anwendungen.