Autonomy Docs
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:

Codetext
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

mablAutonomy
One testOne test case, on the same platform.
PlanA test plan. Set its schedule in the dashboard.
Reusable flowsFolded 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-healNot needed. The agent finds the controls on the live product each run.
AssertionsThe outcome, with the asserted value as a data attachment marked Exact.
WaitsDropped.
Environments and applicationsEnvironments with a target per platform.
Variables{{env.NAME}}, marked secret when it's a credential.
CredentialsSaved sign-ins.
Data tablesOne test case per row only when the rows expect different outcomes. Otherwise test data.
mabl mailboxesA Fresh inbox per run. See Inboxes and phones.
Visual change detectionAn outcome about the look, with a screenshot attachment. See Visual checks.
Plan triggers on deploys and pull requestsA test plan run on pull requests.

See the migration overview for a worked example.

Didn’t find it?

On this page