Appium — qu'est-ce que c'est, principes de fonctionnement et tests multiplateformes

Qu'est-ce qu'Appium

Appium est un framework open source pour l'automatisation des tests d'applications mobiles, construit sur une architecture client-serveur. Le serveur Appium reçoit les commandes du client via le protocole WebDriver et les délègue aux pilotes natifs : XCUITest pour iOS, UiAutomator2 pour Android et WinAppDriver pour Windows.

Histoire et communauté

Appium a été créé en 2013 et est depuis devenu la norme de l'industrie pour les tests multiplateformes. Le projet est géré par l'Appium Foundation et soutenu par de grandes entreprises : Sauce Labs, HeadSpin, Microsoft. Appium est utilisé par plus de 500 000 testeurs dans le monde chaque mois.

Types d'applications pris en charge

Appium prend en charge trois types d'applications : natives (iOS, Android, Windows), les navigateurs web mobiles (Safari, Chrome) et les applications hybrides (WebView dans une coque native). Chaque type utilise son propre contexte : NATIVE_APP, WEBVIEW ou CHROMIUM.

Architecture d'Appium et WebDriver

L'architecture d'Appium se compose de quatre couches : code client → Appium Client Library → Appium Server → pilote natif. La bibliothèque client implémente le protocole WebDriver et envoie des requêtes HTTP au serveur. Le serveur les convertit en commandes du pilote natif de la plateforme.

Protocole WebDriver

WebDriver est une norme W3C pour l'automatisation des navigateurs, adaptée par Appium pour les appareils mobiles. Chaque action — recherche d'élément, tap, saisie de texte — est envoyée comme une requête HTTP au serveur. Par exemple, POST /session/{id}/element crée une nouvelle session de test.

Sessions et Desired Capabilities

Chaque test commence par la création d'une session via l'objet Desired Capabilities. Il spécifie : platformName, deviceName, appPath, automationName et des paramètres supplémentaires. Appium utilise ces données pour sélectionner le pilote natif approprié et la configuration de l'appareil.

# Exemple de Desired Capabilities pour Android
desired_caps = {
    'platformName': 'Android',
    'deviceName': 'Pixel_4',
    'app': '/path/to/app.apk',
    'automationName': 'UiAutomator2',
    'appPackage': 'com.example.app',
    'appActivity': '.MainActivity'
}
driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps)

Installation et configuration d'Appium

Appium s'installe via npm : npm install -g appium. Après l'installation, vous devez configurer les pilotes natifs pour chaque plateforme : appium driver install xcuitest et appium driver install uiautomator2. Xcode est nécessaire pour iOS et Android SDK pour Android.

Appium Inspector

Appium Inspector est un outil graphique pour inspecter les éléments de l'interface utilisateur. Il se connecte à un serveur Appium en cours d'exécution et affiche la hiérarchie des composants de l'interface, leurs attributs et leurs localisateurs. Inspector permet de vérifier un sélecteur avant d'écrire un test.

Démarrage du serveur

Le serveur Appium est démarré avec la commande appium avec des paramètres facultatifs : port, adresse, journalisation. Par défaut, le serveur écoute sur le port 4723. Différents ports ou clusters Appium sont utilisés pour l'exécution parallèle sur plusieurs appareils.

# Démarrage du serveur Appium avec journalisation
appium \
  --port 4723 \
  --log-level debug \
  --use-plugins images \
  --base-path /wd/hub

Rédaction de tests Appium

Les tests Appium utilisent le modèle Page Object pour organiser le code. Chaque écran d'application est décrit par une classe séparée avec des localisateurs d'éléments et des méthodes d'interaction. Le Page Object Model simplifie la maintenance des tests lors des changements d'interface et réutilise les sélecteurs entre les scénarios de test.

Localisateurs d'éléments

Appium prend en charge de nombreuses stratégies de recherche d'éléments : id, xpath, accessibilityId, className, androidUIAutomator et iOSClassChain. Les plus préférés sont accessibilityId et id — ils sont stables malgré les changements de mise en page. XPath ne doit être utilisé que lorsque d'autres localisateurs ne sont pas disponibles.

// Page Object pour l'écran de connexion
public class LoginPage {
    private AppiumDriver driver;

    private MobileElement emailField =
        (MobileElement) driver.findElement(MobileBy.AccessibilityId("emailInput"));
    private MobileElement passwordField =
        (MobileElement) driver.findElement(MobileBy.AccessibilityId("passwordInput"));
    private MobileElement loginButton =
        (MobileElement) driver.findElement(MobileBy.AccessibilityId("loginButton"));

    public void login(String email, String password) {
        emailField.sendKeys(email);
        passwordField.sendKeys(password);
        loginButton.click();
    }
}

Travailler avec les gestes et les actions

Appium prend en charge les gestes complexes via la classe TouchAction ou l'API W3C Actions : balayages, multitouch, pressions longues, défilement vers un élément. La nouvelle API W3C Actions est recommandée pour les nouveaux projets car elle est standardisée et fonctionne de manière plus stable sur différentes versions de plateformes.

Appium vs alternatives

Appium est souvent comparé à Detox, XCUITest et Espresso. Le principal avantage d'Appium est la capacité multiplateforme : un test peut être exécuté sur iOS et Android sans modification. Cependant, Detox offre une meilleure synchronisation pour React Native, et XCUITest/Espresso offrent une exécution plus rapide pour les tests natifs.

Quand choisir Appium

Appium convient aux projets qui nécessitent un framework unique pour iOS, Android et le web. Il est indispensable dans les équipes où les testeurs écrivent en Java ou Python. Pour les projets React Native avec de nombreux tests E2E, envisagez Detox en raison de la synchronisation automatique.

Appium Grid et tests dans le cloud

Appium Grid est une extension pour exécuter des tests en parallèle sur plusieurs appareils simultanément. Appium Grid est construit sur Selenium Grid et permet de distribuer les tests entre plusieurs serveurs Appium, chacun gérant son propre ensemble d'appareils ou d'émulateurs. Ceci est crucial pour les grands projets où les tests de régression sur un seul appareil prennent des heures — Grid réduit le temps à quelques minutes proportionnellement au nombre de nœuds.

Configuration de Grid

La configuration de Grid utilise un fichier de configuration JSON décrivant les nœuds avec des appareils. Chaque nœud spécifie : le port du serveur, la liste des appareils avec la plateforme, la version du système d'exploitation et le nombre maximum de sessions. Le Hub distribue les tests sur les nœuds libres, assurant une utilisation maximale de l'infrastructure.

{
  "capabilities": [
    {
      "browserName": "android",
      "platformName": "Android",
      "deviceName": "Pixel_4",
      "platformVersion": "14.0",
      "maxInstances": 2
    }
  ],
  "configuration": {
    "port": 4724,
    "registerCycle": 5000
  }
}

Services cloud

Si votre propre infrastructure d'appareils n'est pas disponible, il existe des services cloud : Sauce Labs, BrowserStack, LambdaTest. Ils fournissent des centaines d'appareils réels et d'émulateurs dans le cloud. L'intégration avec Appium est minimale : il suffit de spécifier l'URL du hub cloud et les identifiants dans les Desired Capabilities au lieu de localhost.

Exécution parallèle

Appium prend en charge l'exécution parallèle des tests avec TestNG (Java) ou pytest-xdist (Python). La parallélisation nécessite des ports uniques pour chaque session et des données de test isolées. Chaque thread démarre sa propre session Appium sur un appareil ou émulateur séparé. Lors de l'utilisation de services cloud, la parallélisation est automatique — la plateforme distribue les tests sur les appareils disponibles et les libère après leur achèvement.

Diagnostic et débogage d'Appium

Lors de problèmes avec Appium, la première étape consiste à vérifier le journal du serveur (appium --log-level debug). Erreurs typiques : port occupé (spécifiez un autre --port), version de pilote incompatible, Android SDK ou Xcode manquant. Pour iOS, assurez-vous que WebKitAgent est en cours d'exécution et a accès au simulateur.

Problèmes de recherche d'éléments

Si Appium ne trouve pas un élément, vérifiez : le contexte est-il correct (NATIVE_APP vs WEBVIEW), l'élément est-il visible à l'écran, nécessite-t-il un défilement, et le localisateur est-il correct. Utilisez Appium Inspector pour la recherche interactive et la vérification des expressions XPath avant de les insérer dans le test. Il est également utile d'activer l'attente de visibilité de l'élément via WebDriverWait — cela résout les problèmes de synchronisation avec un chargement lent de l'interface.

Gestion des sessions

Une terminaison incorrecte des sessions est une cause fréquente d'instabilité des tests Appium. Fermez toujours le pilote dans un bloc finally ou via AutoCloseable. En cas d'échec, utilisez driver.quit() de force. Pour iOS, assurez-vous que WebKitAgent (WDA) redémarre entre les sessions, sinon une erreur de session non créée peut survenir. Pour surveiller l'état des sessions dans CI, il est pratique de connecter le plugin Appium Dashboard, qui visualise l'état de tous les tests en cours d'exécution en temps réel.

Indicateurs de stabilité

Pour améliorer la stabilité des tests, utilisez : shouldTerminateApp (terminer l'application entre les tests), noReset (conserver les données entre les sessions), autoGrantPermissions (autoriser automatiquement les dialogues système). Il est également recommandé de désactiver les animations sur l'appareil via les Options Développeur.