Maestro : l’outil de tests mobiles qui dépasse Appium en simplicité (14 400 étoiles GitHub)

Tests mobiles natifs × syntaxe YAML = fini les configurations Appium de 300 lignes

Tu veux automatiser tes tests iOS et Android sans passer une semaine à configurer Appium. Maestro te donne une syntaxe YAML déclarative, zéro dépendance complexe, et un support natif de React Native et Flutter dès l’installation. Aujourd’hui tu vas apprendre à :

• Installer Maestro localement sur macOS ou Linux en quelques minutes
• Écrire ton premier flow YAML pour tester une app iOS ou Android
• Comprendre où Maestro bat Appium, et où il est encore limite
• Connecter Maestro à ton pipeline CI/CD via GitHub Actions
• Évaluer si Maestro Cloud vaut le coût additionnel pour ton projet

Ce dont t’as besoin avant de commencer

1. JDK installé sur ta machine

Maestro tourne sur la JVM. Tu as besoin d’un JDK (version 11 ou plus récente recommandée). Si tu n’en as pas, brew install openjdk sur macOS règle ça rapidement. Sans ça, le CLI refuse de démarrer.

2. Android SDK ou Xcode selon ta cible

Pour les tests Android, tu as besoin d’Android SDK avec adb accessible dans ton PATH. Pour iOS, Xcode doit être installé sur macOS. Maestro communique directement avec le simulateur ou l’appareil via ces outils natifs.

3. Un émulateur ou appareil connecté

Lance ton émulateur Android via Android Studio, ou démarre un simulateur iOS via Xcode. Maestro détecte automatiquement le premier appareil disponible. Si tu as plusieurs appareils, tu précises lequel avec --device.

4. Le CLI Maestro installé

Une seule commande :

curl -Ls "https://get.maestro.mobile.dev" | bash

C’est tout. Pas de npm install, pas de pip install, pas de dépendances à gérer manuellement.

5. Ton APK ou IPA à tester

Tu as besoin de l’app installée sur l’émulateur. Pour Android, adb install monapp.apk. Pour iOS sur simulateur, tu peux drag-and-drop le .app directement dans le simulateur.

Le workflow, étape par étape

L’installation via curl place le binaire dans ~/.maestro/bin. Tu dois ajouter ce chemin à ton PATH pour appeler maestro depuis n’importe quel répertoire. Sur macOS avec zsh, c’est une ligne dans ton ~/.zshrc. Sur Linux, ~/.bashrc ou ~/.profile selon ta config.

maestro studio ouvre une interface locale dans le navigateur. Cette interface te permet d’inspecter les éléments de ton app en temps réel, d’identifier les IDs accessibles, et de construire tes flows de manière interactive. C’est l’équivalent de l’inspecteur Appium, mais sans la lourdeur du setup serveur.

Voici la structure d’un flow de connexion typique :

appId: com.tonapp.mobile
---
- launchApp
- tapOn: "Email"
- inputText: "test@exemple.com"
- tapOn: "Mot de passe"
- inputText: "MonMotDePasse"
- tapOn: "Se connecter"
- assertVisible: "Tableau de bord"
- takeScreenshot: login_success

Ce que tu vois ici : chaque action est un item YAML. tapOn accepte un texte visible à l’écran ou un sélecteur d’accessibilité. assertVisible vérifie qu’un élément est présent. takeScreenshot génère une capture à ce moment du test. Aucune ligne de code Java, Kotlin, Swift ou JavaScript requise.

La commande maestro test exécute le flow sur l’appareil connecté. Le terminal affiche chaque action avec un statut (réussi/échoué). En cas d’échec, Maestro génère automatiquement une capture d’écran du moment de l’erreur. Ça élimine le temps passé à comprendre pourquoi un test a planté.

Quand ton projet grossit, tu organises tes flows en fichiers séparés. Un flow setup.yaml pour l’état initial, un login_flow.yaml, un checkout_flow.yaml. Tu les chaînes avec runFlow: ./setup.yaml au début de chaque test qui en a besoin. C’est l’équivalent des beforeEach en Jest, mais déclaratif.

Voici l’essentiel d’un workflow GitHub Actions pour Maestro :

name: Maestro Mobile Tests
on: [push, pull_request]
jobs:
mobile-tests:
runs-on: macos-latest
steps:
- uses: actions/checkout@v4
- name: Installer Maestro CLI
run: curl -Ls "https://get.maestro.mobile.dev" | bash
- name: Ajouter Maestro au PATH
run: echo "$HOME/.maestro/bin" >> $GITHUB_PATH
- name: Démarrer émulateur Android
uses: reactivecircus/android-emulator-runner@v2
with:
api-level: 33
script: maestro test flows/

GitHub Actions inclut 2 000 minutes d’exécution gratuites par mois sur le plan Free. Pour des tests mobiles, les runners macOS consomment plus de minutes que Linux. À planifier dans ton quota selon la fréquence de tes pushes.

Le hic

Soyons clairs. Maestro a des angles morts réels, et les ignorer te coûtera du temps. La gestion des scénarios complexes est encore jeune. Dès que tu as besoin de logique conditionnelle avancée (si X alors Y, boucles sur des listes dynamiques, gestion d’états imprévisibles), le YAML déclaratif de Maestro devient vite limité. Appium, avec ses bindings Java ou Python, te donne un langage de programmation complet. Maestro te donne du YAML, et c’est sa force autant que sa limite. L’écosystème de plugins est moins mature. Appium a plus de 21 600 étoiles GitHub et plusieurs années d’écosystème derrière lui. Des plugins pour la gestion des réseaux, la simulation de conditions réseau dégradées, l’intégration avec des outils de performance spécifiques : Appium a souvent un plugin communautaire, Maestro pas encore. Si ton workflow de tests dépend de cas limites spécialisés, tu vas chercher des solutions qui n’t existent peut-être pas. Maestro Cloud représente un coût additionnel à évaluer sérieusement. Exécuter tes tests sur de vrais appareils physiques (pas des émulateurs) nécessite Maestro Cloud, leur service payant. Pour la CI/CD sur émulateurs seulement, tu t’en tires avec GitHub Actions gratuit. Mais si tu veux des garanties sur des appareils réels variés, l’addition monte. Vérifie leur pricing actuel avant de commit ton architecture. Le debugging d’un flow qui échoue de manière intermittente peut être frustrant. Les tests flaky (qui passent parfois, échouent d’autres fois) existent dans tous les frameworks de tests UI. Avec Maestro, les outils de debugging restent plus limités qu’avec des frameworks matures. Les captures d’écran automatiques aident, mais tu n’as pas encore l’équivalent d’un mode trace complet comme Playwright. Playwright ne remplace pas Maestro pour le mobile natif. L’inverse est aussi vrai : Maestro ne remplace pas Playwright pour le web. Playwright a plus de 88 000 étoiles GitHub et domine les tests web avec raison. Mais pour les apps React Native et Flutter avec du code natif, Playwright s’arrête aux WebViews. Maestro va plus loin.

Quelques trucs bons à savoir

• Maestro identifie les éléments par texte visible, par identifiant d’accessibilité, ou par index. Le texte visible est le plus fragile si ton app change de copie souvent.
• Le flag --format junit sur maestro test génère un rapport XML compatible avec les systèmes CI comme Jenkins ou GitHub Actions sans configuration supplémentaire.
• Pour React Native, tu peux assigner des testID sur tes composants et les cibler directement dans Maestro avec id: "monTestId". C’est plus que cibler par texte.
• Pour Flutter, Maestro utilise le framework Semantics natif. Assure-toi que tes widgets critiques ont des Semantics définis.
• Maestro supporte les flows paramétrés via des variables d’environnement. Tu peux passer MAESTRO_APP_ID=com.autreapp maestro test flow.yaml pour réutiliser le même flow sur différentes apps.
• Le dossier .maestro/ à la racine de ton projet peut contenir ta config globale. Utile pour définir l’appId par défaut et éviter de le répéter dans chaque fichier.
• Sur iOS physique, Maestro nécessite une configuration supplémentaire liée aux certificats de développement Apple. Sur simulateur, ça marche sans friction.

Check-list finale

Verdict + prochaines étapes

Maestro vaut la peine pour toute équipe qui développe une app React Native ou Flutter et qui veut des tests d’intégration UI sans la surcharge de configuration d’Appium. Tu réduis le volume de code de setup de manière significative, et tu démarres à tester en quelques dizaines de minutes plutôt qu’en quelques jours. Évite Maestro si ton projet requiert une logique de test conditionnelle très avancée, si tu dépends d’un écosystème de plugins spécialisés qui n’existe que dans Appium, ou si tu travailles exclusivement sur du web (Playwright reste imbattable dans ce registre). La prochaine étape concrète : installe le CLI, connecte ton émulateur, et écris un flow de cinq actions sur ton écran de connexion. Trente minutes suffisent pour avoir quelque chose qui tourne.

Texte par David Cyr

David Cyr

L'Opérateur AI · Fondateur Taverne AI

Opérateur québécois. J'ai construit LeadLoup, un mandat acheteur véhicules pour Complexe Kia, et plusieurs systèmes IA en production. À la Taverne, je teste des outils qu'on me paie pour utiliser, et je dis si c'est utile ou si c'est de la marde.

À propos·Méthodologie