Docs Autonomy
Migrer

Maestro

Transformez des flows YAML Maestro en cas de test Autonomy Android formés de résultats attendus, sans sélecteurs tapOn ni attentes.

Les flows Maestro sont déjà courts et déclaratifs. La migration conserve ce que vérifie chaque flow et abandonne les commandes qui y mènent : tapOn, inputText, scroll et les attentes entre elles.

Prompt

Collez ce prompt dans un agent de code connecté au serveur MCP Autonomy, depuis le dépôt :

Codetext
Migrez les flows Maestro de ce dépôt vers Autonomy avec les outils MCP Autonomy.

Configuration
1. Appelez autonomy_project_list et demandez-moi quel projet utiliser. Appelez autonomy_environment_list avec son projectId et demandez-moi dans quel environnement exécuter les tests. Vérifiez qu'il a une cible android pour l'appId des flows ; sinon, prévenez-moi avant de créer quoi que ce soit.
2. Appelez autonomy_test_case_list avec le projectId. Ignorez les flows déjà couverts par un cas de test existant.

Pour chaque flow
3. Créez UN cas de test avec autonomy_test_case_create : projectId, name = le nom du flow ou de son fichier, platforms = ["android"]. Les tests iOS ne sont pas encore disponibles : ignorez les flows uniquement iOS et listez-les-moi. Ne migrez pas isolément les sous-flows qui ne s'exécutent que depuis d'autres flows.
4. Rédigez chaque étape comme un résultat attendu : ce qui est vrai une fois l'étape terminée, en langage courant (« Un nouveau compte existe pour une adresse e-mail inédite »). Dites ce que le flow prouve, pas comment : ni tapOn, ni inputText, ni scroll, ni sélecteurs, ni attentes. Une étape peut couvrir plusieurs commandes au service d'un même résultat attendu. Limitez-vous à 12 étapes ; découpez un flow plus long en plusieurs cas de test.
5. Chaque étape est {id, text, attachments[]}. Chaque pièce jointe a un id, un kind et exact. Kinds : account {role}, inbox (sans adresse = une nouvelle boîte de réception par exécution), phone, file, screenshot, data {label, value} ou {label, intent} pour des données générées.
6. N'écrivez jamais de mot de passe, de jeton ni de clé dans une étape. Pour chaque compte avec lequel les flows se connectent (souvent un sous-flow de connexion), demandez-moi de l'enregistrer dans le tableau de bord (Sign-ins du projet, New sign-in) et de vous donner son nom de compte, puis commencez le test par une étape comme « Le propriétaire de la boutique est connecté », avec ce compte en pièce jointe. Pour les autres secrets de env, proposez des noms et référencez-les sous la forme {{env.NAME}} ; ajoutez-les comme valeurs secrètes avec autonomy_environment_upsert seulement après mon accord.
7. Valeurs sur lesquelles porte le flow (le texte vérifié par un assertVisible, un code promo qui doit s'appliquer, une saisie qui doit être refusée) : une pièce jointe data avec exact: true. Autres valeurs de env : {{env.NAME}}.
8. Données d'inscription (e-mails, noms, mots de passe, numéros de téléphone, valeurs aléatoires issues d'evalScript) : une nouvelle boîte de réception, une pièce jointe phone et des données générées, jamais une valeur fixe.
9. Intégrez les sous-flows runFlow aux résultats attendus des flows qui les appellent. Abandonnez launchApp avec clearState (chaque exécution démarre avec une installation propre), extendedWaitUntil, waitForAnimationToEnd, ainsi que les blocs retry et repeat qui ne servent qu'à attendre.

Ensuite
10. Si les flows sont regroupés (tags, dossiers, includes de la configuration), proposez de créer un plan de test par groupe avec autonomy_test_plan_create.
11. Exécutez un cas de test migré avec autonomy_run_trigger dans l'environnement que j'ai choisi. Suivez-le avec autonomy_run_get (en transmettant le dernier cursor et waitMs) jusqu'à ce qu'il se termine. Pour toute étape qui n'a pas réussi, lisez autonomy_run_step_actions et dites-moi ce qui s'est passé.
12. Terminez par un tableau : flow source, ID du cas de test, nombre d'étapes, et tout ce que vous n'avez pas pu faire correspondre.

Correspondances

MaestroAutonomy
Un fichier de flowUn cas de test.
appIdLe build de l'application sur la cible Android de l'environnement. Voir Builds mobiles.
tags, dossiers, includes de la configurationÉventuellement, un plan de test.
tapOn, inputText, scroll, swipe, backIntégrés au résultat attendu de l'étape. L'agent trouve les contrôles.
assertVisible: "Order placed"Le résultat attendu, avec Order placed comme pièce jointe data marquée Exact.
assertNotVisibleUn résultat attendu qui indique ce qui ne doit pas apparaître, comme « Aucune bannière d'erreur n'est affichée ».
launchApp avec clearStateSupprimé. Chaque exécution démarre avec une installation propre, déconnectée.
extendedWaitUntil, waitForAnimationToEnd, retrySupprimés.
runFlowIntégré aux résultats attendus du flow appelant. Un sous-flow de connexion devient une étape de connexion avec une connexion enregistrée.
env et ${VAR}{{env.VAR}}, marquée secrète s'il s'agit d'un identifiant.
Données aléatoires evalScriptDes données générées, ou une Fresh inbox per run pour les e-mails.
takeScreenshotUne pièce jointe screenshot.
repeatUn seul résultat attendu qui énonce l'état final, comme « Le panier contient trois articles ».

Consultez l'aperçu de la migration pour un exemple détaillé.

Vous n’avez pas trouvé ?

On this page