Maestro

Scénarios YAML joués via l'arbre d'accessibilité

Maestro est un framework open source de tests d'interface et de bout en bout pour applications Android, iOS et web. Un test, appelé flow, est un fichier YAML qui aligne des commandes comme launchApp, tapOn, inputText ou assertVisible. La CLI l'interprète tel quel : modifier un flow et le relancer ne demande aucune compilation.

Le moteur traite l'application en boîte noire. Il lit l'arbre d'accessibilité, celui des lecteurs d'écran, et simule les appuis et la saisie au niveau de l'appareil, sans accès au code source.

appId: com.android.contacts
---
- launchApp
- tapOn: "Create new contact"
- tapOn: "First Name"
- inputText: "John"
- tapOn: "Save"

Flows sans sleep() et serveur MCP livré dans la CLI

• Attente intégrée : le moteur attend que l'écran se stabilise ou que le contenu se charge avant d'agir. Les sleep() manuels disparaissent des scénarios.
• Une syntaxe pour tous les frameworks : React Native, Flutter, Android et iOS natifs, Ionic et apps hybrides se testent avec les mêmes commandes. Selon le README, Meta s'en sert pour tester React Native lui-même et Expo en fait sa plateforme E2E de référence.
• Serveur MCP inclus : maestro mcp est livré avec la CLI. Claude Code, Cursor, Codex ou un autre client MCP y pilote l'app sur émulateur, simulateur ou appareil Android, contrôle ce qu'il vient de modifier et peut écrire un flow YAML qu'il relance jusqu'à ce qu'il passe, puis le laisser dans le dépôt comme test de CI.
• Traces lisibles en CI : rapports JUnit et HTML, capture d'écran avant chaque étape, hiérarchie des vues jointe quand une étape échoue.

Simulateurs iOS seulement, web encore en bêta

Pas d'iPhone physique. iOS se teste uniquement sur les simulateurs gérés par Xcode, donc sur un Mac. Depuis la version 2.11.0, la CLI ne liste plus les iPhone branchés et s'arrête d'emblée sur « Physical iOS devices are not yet supported ». Android, lui, tourne sur émulateur comme sur appareil physique.

Java 17 exigé, malgré le « sans dépendance ». Le README promet une installation sans driver, SDK ni dépendance, mais la CLI demande Java 17 ou plus. La page des problèmes connus prévient qu'une version de Java très ancienne ou très récente peut la faire échouer.

Web en bêta, sur Chromium seul. La documentation classe le support web en bêta. Chromium est le seul navigateur pris en charge, dans une copie que Maestro télécharge au premier lancement, avec en-US comme locale par défaut et une taille d'écran prédéfinie.

Des sélecteurs tributaires de l'accessibilité. Sur Android, les problèmes connus citent du contenu de WebView que Maestro ne voit pas toujours. Sur iOS, la doc SwiftUI recommande .accessibilityIdentifier() pour les icônes et les contrôles personnalisés.

Studio gratuit mais fermé, Cloud payant. Le dépôt est sous Apache-2.0, mais Maestro Studio Desktop, l'IDE visuel, n'en fait pas partie : il est gratuit sans être open source. Maestro Cloud, payant après 7 jours d'essai, fait tourner des centaines de tests en parallèle sur une infrastructure dédiée.

Héritier revendiqué d'Appium et d'Espresso. Le README cite comme prédécesseurs Appium, Espresso, UIAutomator, XCTest, Selenium et Playwright, et trois choix de départ : piloter l'app par la couche d'accessibilité, s'installer en binaire unique sans driver ni SDK, écrire chaque test comme une liste plate de commandes YAML.

Neuf versions en six mois, des ruptures en version mineure. Depuis la 2.5.0 du 27 avril 2026, neuf versions ont suivi, jusqu'à la 2.12.0 du 26 octobre. Le changelog de la 2.12.0 signale un changement cassant : une vitesse de défilement hors de l'intervalle 0-100 fait désormais échouer le flow au lieu de revenir à la valeur par défaut.