XCUITest: vad är det, arbetsprinciper och UI-testning av iOS

Vad är XCUITest

XCUITest är ett UI-testramverk som släpptes av Apple i Xcode 7 (2015). Det ersatte UI Automation (UIA) och blev standardverktyget för automatiserad gränssnittstestning på Apple-plattformar. XCUITest är fullständigt integrerat i XCTest — Apples enhetliga testramverk.

Skillnad från XCTest-enhetstester

Till skillnad från enhetstester som kontrollerar logik på klass- och metodnivå, testar XCUITest användargränssnittet genom simulering av åtgärder. Tester körs i en separat process från appen och interagerar med den via Accessibility API — detta säkerställer isolering och tillförlitlighet.

Fördelar med den inbyggda metoden

XCUITest kräver ingen installation av tredjepartsservrar (till skillnad från Appium) eller extra bibliotek för interaktion med enheten. Allt som behövs finns redan i Xcode. Detta ger bästa kompatibilitet med nya iOS-versioner och omedelbar åtkomst till nya gester och kontroller.

Arkitektur för XCUITest och XCTest

Arkitekturen för XCUITest bygger på två nyckelklasser: XCUIApplication — den körda testade appen, och XCUIElement — gränssnittselementet. XCTest-testköraren hanterar testens livscykel: setUp, testmetoder, tearDown. XCUITest körs som en separat process som styr appen via Accessibility-bryggan.

Elementhierarki

Varje UI-element representeras av ett XCUIElement-objekt som innehåller metoder för att fråga efter tillstånd (exists, isHittable, label, value) och åtgärder (tap, pressForDuration, swipeUp, typeText). Element organiseras i en hierarki via frågekedjor: app.buttons[].staticTexts[].tables[]. Detta möjliggör flexibel sökning efter alla element på skärmen.

Accessibility och lokaliserare

XCUITest använder Accessibility-attribut för identifiering av element: accessibilityIdentifier — programmeringsidentifierare, och accessibilityLabel — beskrivning för VoiceOver. Det rekommenderas att ställa in accessibilityIdentifier i appkoden — detta gör testerna stabila oberoende av lokalisering och layout.

Skriva UI-tester i XCUITest

XCUITest-tester skrivs i Swift med XCTest-syntax. Varje testklass ärver från XCTestCase och innehåller metoder som börjar med test. I setUp-metoden startas appen med önskad konfiguration, och i tearDown görs rensning och avslutning av sessionen.

Grundläggande testscenario

Ett typiskt test: hitta element → utför åtgärd → kontrollera resultat. Sökning efter element sker via underordnade XCUIElementQuery-frågor: app.buttons["loginButton"], app.textFields["email"]. Åtgärder: .tap(), .typeText("text"), .swipeUp(). Kontroller: XCTAssertTrue(element.exists) eller 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)
    }
}

Väntan och synkronisering

XCUITest stöder explicita väntan via XCTWaiter och NSPredicate-predikat. Till exempel väntan på att ett element ska visas inom 5 sekunder: XCTWaiter().wait(for: [expectation], timeout: 5). Till skillnad från Detox har XCUITest ingen automatisk synkronisering med nätverksförfrågningar.

// Väntan på att element ska visas med timeout
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)

Avancerade funktioner i XCUITest

XCUITest stöder testning av komplexa scenarier: multitouch-gester, push-notiser, Deep Links, SFSafariViewController och interaktion mellan appar. Siri-avsikter kan också testas via XCUITest med Siri Remote-simulering.

Testning av gester

XCUITest stöder alla populära gester: tap, doubleTap, pressForDuration, swipeUp/Down/Left/Right, pinch, rotate, twoFingerTap. För komplexa scenarier används XCUIGesture med godtyckliga koordinater och varaktighet. Detta möjliggör testning av anpassade gester som ritning eller drag-and-drop.

Avlyssning av nätverksförfrågningar

Från och med Xcode 12 stöder XCUITest avlyssning av nätverksförfrågningar via XCTestExpectation och URLProtocol. Detta möjliggör testning av appen i offlineläge eller med utbytta serversvar utan att ändra appkoden.

XCUITest i CI/CD

XCUITest körs i CI-miljöer via xcodebuild med test-flaggan. För parallell körning på flera simulatorer används xcodebuild -testPlan med konfiguration av parallell exekvering i Xcode-schemat. GitHub Actions, Bitrise och Jenkins har inbyggt stöd för XCUITest.

Konfiguration för CI

För CI krävs konfiguration av code signing, provisioning profiles och angivande av destination (simulator eller enhet). iOS-tester på simulatorn kräver inga certifikat. För verkliga enheter krävs automatisk signering via Xcode Cloud eller Fastlane.

# Köra XCUITest på simulator via xcodebuild
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

Testning av Accessibility via XCUITest

XCUITest är nära kopplat till Apples Accessibility API eftersom elementsökning baseras på tillgänglighetsattribut. Tillgänglighetstestning — är inte bara en metod för att hitta element, utan också kontroll av appens tillgänglighet för personer med funktionsnedsättning. XCUITest kan kontrollera accessibilityLabel, traits och hints.

VoiceOver-kontroll

VoiceOver — Apples skärmläsare för blinda användare. XCUITest möjliggör kontroll: accessibilityLabel — om elementet beskrivs med förståelig text, accessibilityTraits — om elementtypen matchar (knapp, rubrik, bild), och accessibilityHint — om det ger en ledtråd om resultatet av åtgärden. Dessa kontroller är obligatoriska för publicering i App Store och XCUITest automatiserar dem inom ramen för regressionskörningen.

Automatisk Accessibility-kontroll

Från och med Xcode 15 stöder XCUITest inbyggd Accessibility-kontroll via XCTAttachment med typen accessibilityAudit. Testet rapporterar automatiskt element med otillräcklig kontrast, omärkta bilder och felaktiga traits. Detta ersätter manuell Accessibility Inspector.

// Tillgänglighetsgranskning i XCUITest
func testAccessibilityAudit() {
    let app = XCUIApplication()
    app.launch()

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

    // Kontroll av specifikt element
    let button = app.buttons["submitButton"]
    XCTAssertTrue(button.label.count > 0)
    XCTAssertTrue(button.isAccessibilityElement)
}

Prestandatester i XCUITest

XCUITest stöder mätning av UI-prestanda via XCTOSSignpostMetric och XCUIApplication.metrics. Appens starttid (launch time), navigeringshastighet och svarstid på gester kan mätas. Prestandatester körs med baslinjemätning och misslyckas automatiskt när tröskeln överskrids. Detta förhindrar prestandaregressioner innan de når användarna i releaseversionen.

Konfiguration av baslinje

Baslinje — referenstiden för testexekvering. Xcode kommer ihåg baslinjen för varje test på en specifik enhetsmodell och iOS-version. Om en ny körning överskrider baslinjen med en viss procentandel (standard 10%), anses testet misslyckat. För att uppdatera baslinjen används kommandot Edit Baseline i testrapporten. Det är viktigt att räkna om baslinjen vid uppdatering av iOS-versionen eller ändring av enhetsmodell för CI-farmen.

Övervakning av teststabilitet

För att övervaka stabiliteten hos XCUITest-tester används flaggor: continueAfterFailure (om testet ska fortsätta efter första misslyckandet) och Xcode-testplaner med repetitionskonfigurationer. Det rekommenderas att konfigurera automatisk omstart av misslyckade tester (retry) — upp till 3 försök för flaky tester relaterade till animationstimingar eller nätverksförseningar.

Testning av push-notiser och Deep Links

XCUITest stöder testning av push-notiser och Deep Links via springboard och launchArguments. För push-notiser används XCUIApplication().launchArguments med parametern -UNUserNotificationCenter och sändning via XCTest. Deep Links testas via open URL med anpassat schema — XCUITest avlyssnar systemdialogrutan och kontrollerar om appen öppnades på rätt skärm. För testning av svarsscenariot på en notis används XCUIApplication().springboard som simulerar ett klick på notisbannern i iOS-notiscentret. Dessa scenarier är kritiska för appar med djupa länkar och pushkampanjer, där korrekt hantering av externa anrop måste verifieras.

Integration med Instruments

För detaljerad prestandaprofilering integreras XCUITest med Instruments. Under testet kan profilering av Time Profiler, Core Animation eller Leaks startas via XCTMetric. Profileringsresultaten sparas i rapporten och är tillgängliga för analys i Xcode. Detta är särskilt användbart vid optimering av appens starttid, navigering mellan skärmar och prestanda för animationer — typiska flaskhalsar i iOS-appar.