Migrer ses tests mobiles d'Appium vers Maestro : ce que j'en retiens

Sur ma mission actuelle, j’ai piloté la migration des tests mobiles d’une stack Appium + Java + Cucumber vers Maestro. Ce n’est pas une décision qu’on prend à la légère : une suite de tests représente des mois de travail. Voici ce que j’en retiens.

Pourquoi quitter Appium ?

Appium reste une référence, et il a de bonnes raisons d’exister : il est polyvalent, standard, et s’appuie sur WebDriver. Mais sur une suite qui grossit, plusieurs points finissent par peser :

• La lenteur : chaque commande passe par plusieurs couches avant d’atteindre l’appareil.
• L’instabilité : les attentes explicites mal réglées donnent des tests qui échouent au hasard.
• Le coût d’entrée : un projet Java + Cucumber + Appium demande un vrai profil de développeur pour être maintenu.

Ce que Maestro change

Maestro décrit les parcours dans de simples fichiers YAML :

appId: com.exemple.app
---
- launchApp
- tapOn: "Se connecter"
- inputText: "demo@exemple.fr"
- tapOn: "Valider"
- assertVisible: "Bienvenue"

Trois différences m’ont marqué :

1. Les attentes sont gérées par l’outil : Maestro attend que l’écran soit stable avant d’agir, ce qui supprime une grande partie des échecs aléatoires.
2. La lisibilité : un PO ou un testeur fonctionnel lit et écrit un flow sans apprendre Java.
3. La boucle de feedback : on écrit et on rejoue un flow en quelques secondes pendant la mise au point.

Comment s’organiser

Une migration réussie ne consiste pas à traduire les tests un par un. Ma démarche :

1. Faire l’inventaire des scénarios existants, et en profiter pour supprimer ceux qui ne servent plus.
2. Prioriser les parcours critiques, migrés et stabilisés en premier.
3. Faire tourner les deux suites en parallèle le temps de la transition, pour ne jamais perdre en couverture.
4. Factoriser les étapes répétées (connexion, onboarding) dans des sous-flows réutilisables.
5. Mesurer à chaque sprint : nombre de scénarios migrés, taux de réussite, durée d’exécution. Ces KPIs sont présentés en sprint review, ce qui rend l’avancée visible pour tout le monde.

Les pièges à éviter

• Les sélecteurs fragiles : s’appuyer sur des textes affichés est pratique, mais ils changent avec les traductions. Demandez aux devs des identifiants d’accessibilité stables, ça sert aussi l’accessibilité de l’app.
• Vouloir tout faire en YAML : pour la préparation des données (création de comptes, états métier), mieux vaut appeler une API en amont que cliquer dans l’app.
• Oublier la CI : un flow qui ne tourne pas à chaque build se dégrade en silence.

En résumé

Maestro n’est pas magique, mais pour des parcours mobiles de bout en bout, il rend les tests plus rapides à écrire, plus stables et plus lisibles par toute l’équipe. Si vous hésitez, migrez d’abord un seul parcours critique et comparez : les chiffres de votre propre suite vaudront mieux que tous les avis.