Appium
Transformez des tests Appium en Java, Python ou JavaScript en cas de test Autonomy Android formés de résultats attendus, sans capabilities, drivers ni locators.
Les tests Appium sont des tests WebDriver avec des capabilities d'appareil. Dans Autonomy, l'appareil et le build de l'application proviennent de l'environnement, et chaque exécution démarre sur un émulateur Android avec une installation propre. Les tests iOS arrivent bientôt. Voir Mobile et Environnements pour les builds.
Prompt
Collez ce prompt dans un agent de code connecté au serveur MCP Autonomy, depuis le dépôt :
Migrez les tests Appium 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'application ; sinon, prévenez-moi avant de créer quoi que ce soit.
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 titre du test, platforms = ["android"] pour un platformName Android. Les tests iOS ne sont pas encore disponibles : ignorez les tests iOS et listez-les-moi. Si le même test s'exécute sur les deux plateformes, créez un seul cas de test avec ["ios", "android"].
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 touchers, ni balayages, ni locators, ni attentes, ni nouvelles tentatives, ni appels assert. Une étape peut couvrir plusieurs actions 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 la suite se connecte, 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, 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 un assert, un code promo qui doit s'appliquer, une saisie qui doit être refusée) : une pièce jointe data avec exact: true. Autre configuration : {{env.NAME}}.
8. Données d'inscription (e-mails, noms, mots de passe, numéros de téléphone) : 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. Abandonnez les capabilities, le setup du driver, les locators accessibility-id, XPath et UiAutomator, les attentes implicites et explicites, resetApp et noReset (chaque exécution démarre avec une installation propre), ainsi que le code qui ne fait que fermer les boîtes de dialogue d'autorisation (l'agent gère les boîtes de dialogue). Intégrez les balayages et les gestes TouchAction au résultat attendu.
Ensuite
10. Si la suite regroupe des tests (classes, suites, tags), 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 : test source, ID du cas de test, nombre d'étapes, et tout ce que vous n'avez pas pu faire correspondre.Correspondances
| Appium | Autonomy |
|---|---|
| Un test | Un cas de test. Les tests qui s'exécutent sur les deux plateformes deviennent un seul cas de test couvrant les deux. |
platformName | La plateforme du cas de test : Android. Les tests iOS arrivent bientôt. |
Capability app, chemins de build | La cible Android de l'environnement : un build téléversé ou un lien de téléchargement. Voir Builds mobiles. |
| Capabilities d'appareil et d'OS | Inutiles. Les exécutions utilisent les émulateurs Android d'Autonomy. |
click, sendKeys, accessibility-id, XPath, UiAutomator, class chains | Intégrés au résultat attendu de l'étape. L'agent trouve les contrôles. |
Balayages, TouchAction, helpers de défilement | Intégrés au résultat attendu de l'étape. |
| Asserts sur le texte d'un élément | Le résultat attendu, avec le texte attendu comme pièce jointe data marquée Exact. |
| Attentes implicites et explicites, nouvelles tentatives | Supprimées. |
resetApp, noReset, fullReset | Supprimés. Chaque exécution démarre avec une installation propre, déconnectée. |
| Gestion des boîtes de dialogue d'autorisation | Supprimée. L'agent gère les boîtes de dialogue. |
| Helpers de connexion | Une étape de connexion avec une connexion enregistrée jointe comme account. |
| Helpers de vérification par SMS ou e-mail | Une pièce jointe phone ou inbox. Voir Boîtes de réception et téléphones. |
| Appels de capture d'écran | Une pièce jointe screenshot. |
Consultez l'aperçu de la migration pour un exemple détaillé.
Vous n’avez pas trouvé ?
Selenium
Transformez des tests Selenium WebDriver en Java, Python, C# ou JavaScript en cas de test Autonomy formés de résultats attendus, sans objets de page ni attentes explicites.
Maestro
Transformez des flows YAML Maestro en cas de test Autonomy Android formés de résultats attendus, sans sélecteurs tapOn ni attentes.