XCUITest : définition, fonctionnement et tests UI iOS

Qu’est-ce que XCUITest

XCUITest est un framework de test UI publié par Apple dans Xcode 7 (2015). Il a remplacé UI Automation (UIA) et est devenu l’outil standard pour les tests d’interface automatisés sur les plateformes Apple. XCUITest est entièrement intégré à XCTest — le framework de test unifié d’Apple.

Différence avec les tests unitaires XCTest

Contrairement aux tests unitaires qui vérifient la logique au niveau des classes et des méthodes, XCUITest teste l’interface utilisateur par simulation d’actions. Les tests s’exécutent dans un processus séparé de l’application et interagissent avec elle via l’API d’accessibilité — cela garantit l’isolation et la fiabilité.

Avantages de l’approche native

XCUITest ne nécessite pas l’installation de serveurs tiers (contrairement à Appium) ni de bibliothèques supplémentaires pour l’interaction avec l’appareil. Tout le nécessaire est déjà inclus dans Xcode. Cela garantit la meilleure compatibilité avec les nouvelles versions d’iOS et un accès instantané aux nouveaux gestes et contrôles.

Architecture de XCUITest et XCTest

L’architecture de XCUITest repose sur deux classes clés : XCUIApplication — l’application testée lancée, et XCUIElement — l’élément d’interface. L’exécuteur de tests XCTest gère le cycle de vie des tests : setUp, méthodes de test, tearDown. XCUITest s’exécute comme un processus séparé qui contrôle l’application via le pont d’accessibilité.

Hiérarchie des éléments

Chaque élément UI est représenté par un objet XCUIElement contenant des méthodes pour interroger l’état (exists, isHittable, label, value) et les actions (tap, pressForDuration, swipeUp, typeText). Les éléments sont organisés en hiérarchie via des chaînes de requête : app.buttons[].staticTexts[].tables[]. Cela permet de trouver flexiblement n’importe quel élément à l’écran.

Accessibilité et localisateurs

XCUITest utilise les attributs d’accessibilité pour identifier les éléments : accessibilityIdentifier — un identifiant programmatique, et accessibilityLabel — une description pour VoiceOver. Il est recommandé de définir accessibilityIdentifier dans le code de l’application — cela rend les tests stables indépendamment de la localisation et de la mise en page.

Écrire des tests UI avec XCUITest

Les tests XCUITest s’écrivent en Swift en utilisant la syntaxe XCTest. Chaque classe de test hérite de XCTestCase et contient des méthodes commençant par test. Dans la méthode setUp, l’application est lancée avec la configuration nécessaire, et dans tearDown, le nettoyage et la fin de session sont effectués.

Scénario de test de base

Un test typique : trouver un élément → effectuer une action → vérifier le résultat. La recherche d’éléments se fait via des requêtes enfants XCUIElementQuery : app.buttons["loginButton"], app.textFields["email"]. Actions : .tap(), .typeText("text"), .swipeUp(). Vérifications : XCTAssertTrue(element.exists) ou 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)
    }
}

Attentes et synchronisation

XCUITest prend en charge les attentes explicites via XCTWaiter et les prédicats NSPredicate. Par exemple, attendre l’apparition d’un élément dans les 5 secondes : XCTWaiter().wait(for: [expectation], timeout: 5). Contrairement à Detox, XCUITest n’a pas de synchronisation automatique avec les requêtes réseau.

// Attente de l’apparition de l’élément avec délai d’expiration
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)

Fonctionnalités avancées de XCUITest

XCUITest prend en charge les tests de scénarios complexes : gestes multitouch, notifications push, Deep Links, SFSafariViewController et interactions inter-applications. Les intents Siri peuvent également être testés via XCUITest avec la simulation Siri Remote.

Test des gestes

XCUITest prend en charge tous les gestes courants : tap, doubleTap, pressForDuration, swipeUp/Down/Left/Right, pinch, rotate, twoFingerTap. Pour les scénarios complexes, XCUIGesture est utilisé avec des coordonnées et une durée personnalisées. Cela permet de tester des gestes personnalisés comme le dessin ou le glisser-déposer.

Interception des requêtes réseau

À partir de Xcode 12, XCUITest prend en charge l’interception des requêtes réseau via XCTestExpectation et URLProtocol. Cela permet de tester l’application en mode hors ligne ou avec des réponses serveur simulées sans modifier le code de l’application.

XCUITest dans le CI/CD

XCUITest s’exécute dans les environnements CI via xcodebuild avec le flag test. Pour l’exécution parallèle sur plusieurs simulateurs, on utilise xcodebuild -testPlan avec une configuration d’exécution parallèle dans le schéma Xcode. GitHub Actions, Bitrise et Jenkins ont un support intégré pour XCUITest.

Configuration pour le CI

Pour le CI, il faut configurer la signature de code, les profils de provisionnement et spécifier la destination (simulateur ou appareil). Les tests iOS sur simulateur ne nécessitent pas de certificats. Pour les appareils réels, une signature automatique est nécessaire via Xcode Cloud ou Fastlane.

# Exécution de XCUITest sur simulateur 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

Test d’accessibilité avec XCUITest

XCUITest est étroitement lié à l’API d’accessibilité d’Apple, car la recherche d’éléments est basée sur les attributs d’accessibilité. Le test d’accessibilité n’est pas seulement un moyen de trouver des éléments, mais aussi de vérifier l’accessibilité de l’application pour les personnes handicapées. XCUITest peut vérifier accessibilityLabel, traits et hints.

Vérification VoiceOver

VoiceOver est le lecteur d’écran d’Apple pour les utilisateurs malvoyants. XCUITest permet de vérifier : accessibilityLabel — si l’élément est décrit avec un texte clair, accessibilityTraits — si le type d’élément correspond (bouton, titre, image), et accessibilityHint — s’il fournit une indication sur le résultat de l’action. Ces vérifications sont obligatoires pour la publication sur l’App Store, et XCUITest les automatise dans le cadre des exécutions de régression.

Vérification automatique de l’accessibilité

À partir de Xcode 15, XCUITest prend en charge la vérification intégrée de l’accessibilité via XCTAttachment avec le type accessibilityAudit. Le test signale automatiquement les éléments avec un contraste insuffisant, les images non étiquetées et les traits incorrects. Cela remplace l’inspecteur d’accessibilité manuel.

// Audit d’accessibilité dans XCUITest
func testAccessibilityAudit() {
    let app = XCUIApplication()
    app.launch()

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

    // Vérification d’un élément spécifique
    let button = app.buttons["submitButton"]
    XCTAssertTrue(button.label.count > 0)
    XCTAssertTrue(button.isAccessibilityElement)
}

Tests de performance dans XCUITest

XCUITest prend en charge la mesure des performances UI via XCTOSSignpostMetric et XCUIApplication.metrics. On peut mesurer le temps de démarrage de l’application, la vitesse de navigation et le temps de réponse aux gestes. Les tests de performance sont exécutés avec une mesure de référence et échouent automatiquement lorsque le seuil est dépassé. Cela permet d’éviter les régressions de performance avant qu’elles n’atteignent les utilisateurs dans une version de publication.

Configuration de la référence

La référence (baseline) est le temps d’exécution de référence d’un test. Xcode mémorise la référence pour chaque test sur un modèle d’appareil et une version iOS spécifiques. Si une nouvelle exécution dépasse la référence d’un pourcentage défini (par défaut 10%), le test est considéré comme échoué. Pour mettre à jour la référence, utilisez la commande Edit Baseline dans le rapport de test. Il est important de recalculer la référence lors de la mise à jour de la version iOS ou du changement de modèle d’appareil pour la ferme CI.

Surveillance de la stabilité des tests

Pour surveiller la stabilité des tests XCUITest, des flags sont utilisés : continueAfterFailure (continuer le test après le premier échec) et les plans de test Xcode avec des configurations de réessai. Il est recommandé de configurer le redémarrage automatique des tests échoués (retry) — jusqu’à 3 tentatives pour les tests instables liés au timing des animations ou aux délais réseau.

Test des notifications push et Deep Links

XCUITest prend en charge le test des notifications push et des Deep Links via springboard et launchArguments. Pour les notifications push, on utilise XCUIApplication().launchArguments avec le paramètre -UNUserNotificationCenter et l’envoi via XCTest. Les Deep Links sont testés via open URL avec un schéma personnalisé — XCUITest intercepte la boîte de dialogue système et vérifie si l’application s’est ouverte avec le bon écran. Pour tester le scénario de réponse à une notification, on utilise XCUIApplication().springboard, qui simule le tap sur la bannière de notification dans le centre de notifications iOS. Ces scénarios sont critiques pour les applications avec des deep links et des campagnes push, où il est nécessaire de vérifier le traitement correct des appels externes.

Intégration avec Instruments

Pour le profilage détaillé des performances, XCUITest s’intègre à Instruments. Pendant le test, le profilage de Time Profiler, Core Animation ou Leaks peut être lancé via XCTMetric. Les résultats du profilage sont enregistrés dans le rapport et disponibles pour analyse dans Xcode. Ceci est particulièrement utile pour optimiser le temps de démarrage de l’application, la navigation entre les écrans et les performances des animations — des goulots d’étranglement typiques dans les applications iOS.