Maestro - framework de test UI automatisé pour applications mobiles

• La manière la plus simple d’automatiser les tests UI d’applications mobiles
• Tolérance intrinsèque à l’instabilité des éléments UI
  • Les éléments UI ne se trouvent pas toujours à l’emplacement attendu, donc appuyer sur l’écran ne fonctionne pas forcément à tous les coups
  • Conçu pour accepter l’instabilité des applications mobiles et des appareils, et y répondre
• Tolérance intrinsèque aux délais
  • Pas besoin d’ajouter des appels à sleep() dans les tests
  • Sait que le chargement de contenu (par exemple via le réseau) peut prendre du temps et attend automatiquement, sans attendre plus longtemps que nécessaire
• Permet des itérations très rapides
  • Les tests sont interprétés, il n’est donc pas nécessaire de les compiler
  • Peut surveiller en continu les fichiers de test et les relancer lorsqu’ils changent
• Fournit une syntaxe déclarative mais puissante
  • Les tests sont définis dans des fichiers yaml
• Configuration simple
  • Un binaire unique qui fonctionne partout

L’avis de GN⁺

• Maestro est un nouvel outil d’automatisation des tests d’applications mobiles, qui cherche à dépasser les limites d’Appium, Espresso, UIAutomator, XCTest, etc. Sa tolérance intrinsèque à l’instabilité des éléments UI et aux délais pourrait notamment réduire les problèmes fréquemment rencontrés avec les outils existants.
• Comme il utilise une syntaxe déclarative basée sur YAML, même des ingénieurs QA non développeurs devraient pouvoir écrire facilement des cas de test. Cela dit, si l’on n’est pas familier avec la syntaxe YAML, un coût d’apprentissage existe.
• Parmi les outils d’automatisation de tests mobiles, Appium est largement utilisé. Son principal avantage est de prendre en charge plusieurs plateformes mobiles et langages de programmation, mais il souffre d’un taux d’échec élevé des tests en raison de problèmes de stabilité. Il faudra voir dans quelle mesure Maestro parvient à résoudre ces faiblesses d’Appium.
• À l’heure actuelle, Maestro dispose d’une documentation bien fournie et d’une communauté Slack active, ce qui en fait un outil qui mérite d’être envisagé. Comme il s’agit encore d’une version précoce, une validation approfondie semble toutefois nécessaire avant une utilisation en production.

[laeyoung]

Après essai, c’est plutôt pas mal, car on peut le faire rapidement (environ moins d’une heure, de la configuration à la création du premier fichier YAML de test).

[rabolution]

Maestro est simple et a beaucoup d’atouts. Mais sur Android, il y a encore un problème de saisie en coréen : https://github.com/mobile-dev-inc/maestro/issues/146

Un autre point regrettable, c’est qu’il ne s’exécute pas rapidement comparé à d’autres outils de test. En général, les outils de test s’exécutent très vite, contrairement à un utilisateur réel, donc si les wait ne sont pas conçus avec précision, on peut avoir des échecs de test intermittents. Maestro est si lent qu’on en vient presque à se demander s’ils n’ont pas simplement choisi de résoudre le problème en attendant lentement. ^^;;;

[rabolution]

D’un côté, dans les tests de frontend web, l’approche qui consiste à exploiter les éléments d’accessibilité gagne en popularité, et c’est aussi le cas sur mobile. (voir https://blog.banksalad.com/tech/test-in-banksalad-ios-2/)

Comme Maestro se concentre surtout sur le texte et les id, il est difficile de distinguer les rôles comme link, button ou heading pour « liste de produits ». Sur le web, c’est aussi dommage de ne pas pouvoir vérifier certains aspects avec aria-checked, aria-expanded, etc.

De mon côté, j’avais tendance à ajouter des préfixes aux test-id pour éviter les collisions d’id, et au final, c’était contraignant de devoir retester si l’élément récupéré de cette façon affichait bien le texte attendu.

[smboy86]

Merci pour ce commentaire riche en insights.