Aller au contenu

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).