Docs Autonomy
Migrer

mabl

Transformez les tests, flows réutilisables et plans mabl en cas de test et plans de test Autonomy, sans modèles d'éléments ni auto-heal.

Les tests mabl vivent dans le cloud de mabl. Exportez-les d'abord, par exemple sous forme de code Playwright ou de JSON, dans un dossier que votre agent de code peut lire. Migrez ensuite cet export : chaque test mabl devient un cas de test Autonomy, et chaque plan mabl peut devenir un plan de test.

Prompt

Collez ce prompt dans un agent de code connecté au serveur MCP Autonomy, depuis le dossier qui contient l'export :

Codetext
Migrez les tests mabl exportés dans ce dossier 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. Les environnements et applications mabl correspondent aux environnements Autonomy ; prévenez-moi s'il en manque un.
2. Appelez autonomy_test_case_list avec le projectId. Ignorez les tests déjà couverts par un cas de test existant.

Pour chaque test
3. Créez UN cas de test avec autonomy_test_case_create : projectId, name = le nom du test mabl, platforms = ["web"] pour les tests navigateur, ["api"] pour les tests d'API, ["android"] pour les tests Android. Les tests iOS ne sont pas encore disponibles : ignorez les tests iOS et listez-les-moi.
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 test prouve, pas comment : ni clics, ni recherches d'éléments, ni attentes, ni étapes d'assertion. Une étape peut couvrir plusieurs actions enregistrées au service d'un même résultat attendu. Limitez-vous à 12 étapes ; découpez un test 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 tests se connectent (identifiants mabl, flows 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 variables secrètes, 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 test (le texte vérifié par une assertion, un code promo qui doit s'appliquer, une saisie qui doit être refusée) : une pièce jointe data avec exact: true. Autres variables : {{env.NAME}}.
8. Données d'inscription (e-mails des boîtes mabl, noms générés, mots de passe) : une nouvelle boîte de réception et des données générées, jamais une valeur fixe.
9. Intégrez les flows réutilisables aux résultats attendus des tests qui les utilisent. Pour les tests pilotés par les données, ne créez un cas de test par ligne du tableau de données que si les lignes attendent des résultats différents ; sinon, utilisez des données de test. Si l'export est du code Playwright, appliquez-lui les mêmes règles.

Ensuite
10. Proposez de créer un plan de test par plan mabl avec autonomy_test_plan_create, avec les cas de test migrés comme testCaseIds.
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 : test source, ID du cas de test, nombre d'étapes, et tout ce que vous n'avez pas pu faire correspondre.

Correspondances

mablAutonomy
Un testUn cas de test, sur la même plateforme.
PlanUn plan de test. Définissez sa planification dans le tableau de bord.
Flows réutilisablesIntégrés aux résultats attendus des tests qui les utilisent. Un flow de connexion devient une étape de connexion avec une connexion enregistrée.
Clics enregistrés, modèles d'éléments, auto-healInutiles. L'agent trouve les contrôles sur le produit en ligne à chaque exécution.
AssertionsLe résultat attendu, avec la valeur vérifiée comme pièce jointe data marquée Exact.
AttentesSupprimées.
Environnements et applicationsDes environnements avec une cible par plateforme.
Variables{{env.NAME}}, marquée secrète s'il s'agit d'un identifiant.
IdentifiantsDes connexions enregistrées.
Tableaux de donnéesUn cas de test par ligne uniquement si les lignes attendent des résultats différents. Sinon, des données de test.
Boîtes de réception mablUne Fresh inbox per run. Voir Boîtes de réception et téléphones.
Détection des changements visuelsUn résultat attendu portant sur l'apparence, avec une pièce jointe screenshot. Voir Vérifications visuelles.
Déclencheurs de plan sur les déploiements et les pull requestsUn plan de test exécuté sur les pull requests.

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

Vous n’avez pas trouvé ?

On this page