E2E-Tests von Swift-Apps: Von XCUITest bis zu realen Anwendungsfällen

Warum E2E-Tests der „Gott-Modus“ für iOS-Entwickler sind?

Stellen Sie sich vor: Sie haben perfekten Swift-Code geschrieben, alles kompiliert, die Unit-Tests sind grün. Sie veröffentlichen einen Release – und eine Stunde später hagelt es Bugs: Der „Kaufen“-Button funktioniert nicht auf dem iPhone 14 Pro, und auf dem iPad Mini sieht der Anmeldebildschirm aus wie abstrakte Kunst. Kommt Ihnen bekannt vor? Genau hier kommt E2E-Testing von Swift ins Spiel – der einzige Weg, um sicherzustellen, dass Ihre App in den Händen eines echten Benutzers wie am Schnürchen läuft.

End-to-End (E2E)-Tests simulieren ein vollständiges Benutzerszenario: vom Start der App bis zur Ausführung der Zielaktion (Kauf, Registrierung, Formularabsendung). In diesem Artikel zeigen wir Ihnen, wie Sie XCUITest Swift so einrichten, dass Ihre Tests nicht aus nichtigen Gründen fehlschlagen und Ihre CI/CD-Pipeline nicht zur Hölle wird.

Was Sie lernen werden:

\n
• Wie man stabile UI-Tests mit XCUITest schreibt
\n
• Page Object Model für Swift – ein praktisches Beispiel
\n
• Umgang mit asynchronen Operationen und Wartezeiten
\n
• Integration von E2E-Tests in CI/CD (GitHub Actions + Fastlane)
\n
• Die Top-3 Anfängerfehler und wie man sie vermeidet
\n

Werkzeuge: Was wir brauchen

Für die Testautomatisierung von Swift verwenden wir drei Säulen:

\n
1. XCUITest – ein Framework von Apple, integriert in XCTest. Ermöglicht die Emulation von Gesten und die Überprüfung von UI-Element-Zuständen.
\n
2. Xcode Test Plan – zur Konfiguration von Testschemata (verschiedene Sprachen, Ausrichtungen, Daten).
\n
3. Fastlane + GitHub Actions – zum Ausführen von Tests in CI.
\n

Die grundlegende Syntax von XCUITest ist einfach: Sie erhalten Zugriff auf die App über XCUIApplication(), suchen Elemente über buttons["Login"] oder textFields["email"] und simulieren Aktionen.

Den ersten E2E-Test schreiben: Ein Login-Szenario

Angenommen, wir haben einen Anmeldebildschirm mit den Feldern E-Mail, Passwort und einem „Anmelden“-Button. Ziel: Überprüfen, ob der Benutzer bei Eingabe korrekter Daten zum Hauptbildschirm weitergeleitet wird.

import XCTest\n\nclass LoginE2ETests: XCTestCase {\n    \n    let app = XCUIApplication()\n    \n    override func setUpWithError() throws {\n        continueAfterFailure = false\n        app.launch()\n    }\n    \n    func testSuccessfulLogin() throws {\n        // 1. Elemente finden\n        let emailField = app.textFields["emailTextField"]\n        let passwordField = app.secureTextFields["passwordTextField"]\n        let loginButton = app.buttons["signInButton"]\n        \n        // 2. Benutzeraktionen\n        emailField.tap()\n        emailField.typeText("user@example.com")\n        \n        passwordField.tap()\n        passwordField.typeText("ValidPassword123")\n        \n        loginButton.tap()\n        \n        // 3. Ergebnis überprüfen\n        let dashboard = app.staticTexts["dashboardTitle"]\n        XCTAssertTrue(dashboard.waitForExistence(timeout: 5))\n    }\n}

Wichtiger Punkt: Verwenden Sie waitForExistence(timeout:) – ohne dies kann der Test fehlschlagen, wenn eine Animation oder eine Netzwerkanfrage Verzögerungen verursacht. Das ist die Grundlage des E2E-Testings von Swift.

Warum könnte dieser Code fehlschlagen?

\n
• Das Eingabefeld ist möglicherweise nicht der erste Responder – fügen Sie .tap() vor typeText hinzu.
\n
• Der Button könnte von der Tastatur verdeckt sein – verwenden Sie app.keyboards.buttons["Return"].tap().
\n
• Textbezeichnungen können je nach Lokalisierung variieren – verwenden Sie immer Accessibility Identifier.
\n

Page Object Model (POM) für Swift: Tests sauber halten

Wenn die App wächst, werden Tests schnell unübersichtlich. Die Lösung ist das Page Object Model. Wir erstellen separate Klassen für jeden Bildschirm, die die Logik zum Auffinden von Elementen und Aktionen kapseln.

Beispiel für den Anmeldebildschirm:

// Lo