Maestro : tests UI mobiles automatises en YAML pour React Native¶
Resume¶
Maestro est un framework de test UI mobile end-to-end en YAML. Tests lisibles par un humain (tapOn, assertVisible, inputText), executes sans compilation, avec resilience integree (attente intelligente des elements dynamiques). Supporte Android, iOS, React Native, Flutter, et web. 13.3k stars, Apache 2.0, v2.3.0. Kotlin (77%) + TypeScript + Objective-C + Swift.
Analyse critique¶
Ce qui est solide : - Le DSL YAML est le bon choix pour des tests generes par LLM. Un agent en step 7 pourrait lire la spec, generer les flows YAML, et Maestro les execute de maniere deterministe. Pas besoin d'ecrire du code Playwright/Detox. - Support React Native natif — c'est la stack ProbatioVault-app (Expo SDK 54). - CLI-first — fonctionne en CI/CD et en subprocess, contrairement a Computer Use (pas de mode -p). - 13.3k stars, 134 releases — mature et maintenu. - Tests reproductibles (YAML deterministe) vs Computer Use (screenshots non-deterministes).
Ce qui est a nuancer : - Maestro teste le comportement UI (tap, assert, input), pas le rendu visuel (layout, couleurs, responsive). Pour le rendu visuel, il faudrait combiner avec Computer Use ou des screenshots de reference. - Le YAML est simple mais peut devenir verbeux pour des flows complexes (auth SRP, crypto, multi-ecrans). - Pas de support natif pour les assertions sur les donnees chiffrees (zero-knowledge) — il faut des stubs cote backend.
Comparaison avec les alternatives :
| Outil | Type | Mode | Deterministe | Mobile natif | Generable par LLM |
|---|---|---|---|---|---|
| Maestro | YAML flows | CLI (CI/CD) | Oui | Oui (RN, Flutter) | Oui (YAML simple) |
| Computer Use | Screenshots + clics | Interactif only | Non | Oui (Simulator) | Non (pas de -p) |
| Playwright | Code JS/TS | CLI (CI/CD) | Oui | Non (web only) | Possible mais verbeux |
| Detox | Code JS | CLI (CI/CD) | Oui | Oui (RN) | Possible mais complexe |
| ObviousUI-QA | Deterministe | CLI | Oui | Non | Non |
Pertinence ProbatioVault¶
Impact fort. Maestro est le chainon manquant pour les tests d'acceptabilite mobile en step 7.
Integration dans le workflow : 1. Step 7 (acceptabilite) : apres les reviews LLM (7a/7b/7c), lancer Maestro avec des flows YAML generes depuis la spec. Chaque flow correspond a un critere d'acceptation (CA-XX). Resultat deterministe : pass/fail. 2. Step 6b (agents) : un agent agent-qa-maestro pourrait generer les flows YAML a partir de la spec et des tests contractuels (PD-XX-tests.md). Le YAML est assez simple pour qu'un LLM le genere correctement. 3. CI/CD : Maestro tourne en CLI, integreable dans le pipeline GitLab. Les tests Maestro deviendraient une gate bloquante avant Gate 8.
Exemple de flow pour ProbatioVault-app :
appId: com.probatiovault.app
---
- launchApp
- tapOn: "Se connecter"
- inputText:
id: "email-input"
text: "test@probatiovault.com"
- tapOn: "Continuer"
- assertVisible: "Entrez votre mot de passe"
- inputText:
id: "password-input"
text: "TestPassword123!"
- tapOn: "Se connecter"
- assertVisible: "Mes documents"
Lien avec le TODO #9 : Maestro remplace ObviousUI-QA pour les stories mobile (meilleur support React Native), mais ne couvre pas l'accessibilite visuelle (contraste, daltonisme, taille zones tap). Strategie complete pour ProbatioVault-app en step 7 :
| Couche | Outil | Mode | Automatisable CI |
|---|---|---|---|
| Tests fonctionnels + labels a11y | Maestro (YAML) | CLI | Oui |
| Audit contraste + structure a11y | axe-core / react-native-a11y | CI | Oui |
| Audit visuel daltonisme + VoiceOver | Computer Use (quand -p dispo) | Interactif | Non (pour l'instant) |
TODO #9 scinde en : #9a Maestro (mobile, priorite haute), #9b ObviousUI-QA/Playwright (web, priorite basse), #9c Computer Use (pixel-governance, en attente -p).