Playwright
Transformez chaque test Playwright en un cas de test Autonomy formé de résultats attendus, sans ses locators, ses attentes ni ses objets de page.
Un test Playwright se lit déjà comme un parcours : ouvrir une page, faire quelque chose, attendre un résultat. La migration conserve le résultat que chaque test attend et abandonne les locators, les appels waitFor, les objets de page et les fixtures qui permettent d'y arriver.
Prompt
Collez ce prompt dans un agent de code connecté au serveur MCP Autonomy, depuis le dépôt :
Migrez les tests Playwright 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.
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 = ["web"] (["api"] pour les tests qui n'utilisent que la fixture request).
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 locators, ni attentes, ni nouvelles tentatives, ni appels expect. 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 (storageState, global setup, helpers 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 process.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 test (le texte ou le nombre vérifié par un expect, 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, suffixes Date.now()) : une nouvelle boîte de réception et des données générées, jamais une valeur fixe.
9. Intégrez les objets de page et les fixtures dans ce que le test prouve. Abandonnez les mocks page.route : les exécutions testent le vrai produit. Si un test ne fonctionne qu'avec des réponses simulées, ne le migrez pas ; listez-le à la place. Transformez les vérifications waitForResponse en un résultat attendu portant sur ce que voit l'utilisateur.
Ensuite
10. Si la suite regroupe des tests (blocs test.describe, tags, projects 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 : test source, ID du cas de test, nombre d'étapes, et tout ce que vous n'avez pas pu faire correspondre.Correspondances
| Playwright | Autonomy |
|---|---|
test() | Un cas de test. |
test.describe(), tags, projects de la configuration | Éventuellement, un plan de test. |
page.goto, click, fill, locators, objets de page | Intégrés au résultat attendu de l'étape. L'agent trouve les contrôles. |
expect(...).toHaveText("$48.00") | Le résultat attendu, avec $48.00 comme pièce jointe data marquée Exact. |
waitFor*, toPass, nouvelles tentatives, délais | Supprimés. |
storageState, connexion dans le global setup | Une étape de connexion avec une connexion enregistrée jointe comme account. |
process.env.X | {{env.X}}, marquée secrète s'il s'agit d'un identifiant. |
baseURL | La cible Web de l'environnement. |
Tests avec la fixture request | Un cas de test sur la plateforme API, avec l'URL de base comme cible API de l'environnement. Voir API et réseau. |
setInputFiles | Une pièce jointe file issue des Files du projet. |
toHaveScreenshot() | Un résultat attendu portant sur l'apparence, avec une pièce jointe screenshot. Voir Vérifications visuelles. |
Mocks page.route | Non migrés. Les exécutions utilisent le vrai produit. |
Vérifications waitForResponse | Un résultat attendu portant sur le résultat. L'exécution conserve chaque requête dans son onglet Network. |
| Projects d'émulation d'appareil | Toujours du web. Pour une application native, suivez le guide Appium ou Maestro. |
Consultez l'aperçu de la migration pour un exemple détaillé.
Vous n’avez pas trouvé ?
Aperçu
Migrez une suite Playwright, Cypress, Puppeteer, Selenium, Appium, Maestro ou mabl vers Autonomy avec un seul prompt donné à votre agent de code.
Cypress
Transformez chaque test Cypress en un cas de test Autonomy formé de résultats attendus, sans ses chaînes cy.get, ses intercepts ni ses commandes personnalisées.