Migrate
mabl
Turn mabl tests, reusable flows and plans into Autonomy test cases and test plans, without element models and auto-heal.
mabl tests live in mabl's cloud. Export them first, for example as Playwright code or JSON, into a folder your coding agent can read. Then migrate the export: each mabl test becomes one Autonomy test case, and each mabl plan can become a test plan.
Prompt
Paste this into a coding agent connected to the Autonomy MCP server, from inside the folder that holds the export:
Migrate the exported mabl tests in this folder to Autonomy with the Autonomy MCP tools.
Setup
1. Call autonomy_project_list and ask me which project to use. Call autonomy_environment_list with its projectId and ask me which environment to run in. mabl environments and applications map to Autonomy environments; tell me if one is missing.
2. Call autonomy_test_case_list with the projectId. Skip tests that an existing test case already covers.
For each test
3. Create ONE test case with autonomy_test_case_create: projectId, name = the mabl test name, platforms = ["web"] for browser tests, ["api"] for API tests, ["android"] for Android tests. iOS testing isn't available yet: skip iOS tests and list them for me.
4. Write each step as an outcome: what is true when the step is done, in plain words ("A new account exists for a fresh email"). Say what the test proves, not how: no clicks, element finds, waits or assertion steps. One step can cover several recorded actions that serve one outcome. Use 12 steps or fewer; split a longer test into several test cases.
5. Each step is {id, text, attachments[]}. Each attachment has id, kind and exact. Kinds: account {role}, inbox (no address = a fresh inbox per run), phone, file, screenshot, data {label, value} or {label, intent} for generated data.
6. Never write a password, token or key into a step. For each account the tests sign in as (mabl credentials, login flows), ask me to save it in the dashboard (the project's Sign-ins, New sign-in) and tell you its account name, then start the test with a step such as "The store owner is signed in" with that account attached. For other secret variables, propose names and reference them as {{env.NAME}}; add them as secret values with autonomy_environment_upsert only after I agree.
7. Values the test is about (the text an assertion checks, a coupon that must apply, input that must be refused): a data attachment with exact: true. Other variables: {{env.NAME}}.
8. Sign-up data (emails from mabl mailboxes, generated names, passwords): a fresh inbox and generated data, never a fixed value.
9. Inline reusable flows into the outcomes of the tests that use them. For data-driven tests, create one test case per data table row only when the rows expect different outcomes; otherwise use test data. If the export is Playwright code, apply the same rules to it.
Afterwards
10. Offer to create one test plan per mabl plan with autonomy_test_plan_create, with the migrated test cases as testCaseIds.
11. Run one migrated test case with autonomy_run_trigger in the environment I picked. Follow it with autonomy_run_get (pass the last cursor and waitMs) until it ends. For any step that didn't pass, read autonomy_run_step_actions and tell me what happened.
12. Finish with a table: source test, test case ID, number of steps, and anything you couldn't map.Mapping
| mabl | Autonomy |
|---|---|
| One test | One test case, on the same platform. |
| Plan | A test plan. Set its schedule in the dashboard. |
| Reusable flows | Folded into the outcomes of the tests that use them. A login flow becomes a signed-in step with a saved sign-in. |
| Recorded clicks, element models, auto-heal | Not needed. The agent finds the controls on the live product each run. |
| Assertions | The outcome, with the asserted value as a data attachment marked Exact. |
| Waits | Dropped. |
| Environments and applications | Environments with a target per platform. |
| Variables | {{env.NAME}}, marked secret when it's a credential. |
| Credentials | Saved sign-ins. |
| Data tables | One test case per row only when the rows expect different outcomes. Otherwise test data. |
| mabl mailboxes | A Fresh inbox per run. See Inboxes and phones. |
| Visual change detection | An outcome about the look, with a screenshot attachment. See Visual checks. |
| Plan triggers on deploys and pull requests | A test plan run on pull requests. |
See the migration overview for a worked example.
Didn’t find it?