Overview

Your existing tests already say which journeys matter. The selectors, waits, page objects and fixtures around them are the part that breaks. A migration keeps the first and drops the second: each test becomes one Autonomy test case, written as a few outcome steps, and the agent works out the clicks on the live product at run time.

How it works

1. Connect your coding agent to Autonomy over MCP. See Connect a client. When it asks for access, allow Create and edit test cases, Create and edit test plans and Start runs. Add Create and edit environments if you want it to add environment values for you.
2. Open the repository that holds the suite and paste the prompt from your framework's page.
3. The agent starts with autonomy_project_list and autonomy_environment_list, asks you which project and environment to use, and checks autonomy_test_case_list so it doesn't duplicate coverage.
4. It creates one test case per test with autonomy_test_case_create, optionally groups them with autonomy_test_plan_create, runs one, and reads the result with autonomy_run_get and autonomy_run_step_actions.

For a handful of tests, you can also use Describe what to test in the dashboard: describe the journey, or attach a .feature file, and Autonomy drafts the steps. See Authoring.

What a test becomes

A test case has up to 12 steps in the dashboard and up to 50 through the API. Keep migrated test cases to 12 steps or fewer so people can still edit them; split a longer test into several test cases.

Example

A Playwright test:

test("sign up and apply a coupon", async ({ page }) => {
  await page.goto("/signup");
  await page.fill("#email", `qa+${Date.now()}@example.com`);
  await page.fill("#password", "Hunter2!Hunter2!");
  await page.click("button[type=submit]");
  await page.goto(await verificationLink());
  await expect(page.getByText("Email verified")).toBeVisible();
  await page.goto("/plans");
  await page.fill("[name=coupon]", "SPRING25");
  await expect(page.locator(".total")).toHaveText("$37.50");
});

becomes three outcome steps. The random email turns into a fresh inbox, the password into generated data, and the coupon and total are Exact because the test is about them:

{
  "projectId": "<project id>",
  "name": "Sign up and apply a coupon",
  "platforms": ["web"],
  "steps": [
    {
      "id": "s1",
      "text": "A new account exists for a fresh email.",
      "attachments": [
        { "id": "a1", "kind": "inbox", "exact": false },
        { "id": "a2", "kind": "data", "label": "Password", "intent": "a strong password", "exact": false }
      ]
    },
    {
      "id": "s2",
      "text": "The verification email arrives and its link verifies the account.",
      "attachments": []
    },
    {
      "id": "s3",
      "text": "On the Plans page, the coupon applies and the total shows $37.50.",
      "attachments": [
        { "id": "a3", "kind": "data", "label": "Coupon", "value": "SPRING25", "exact": true },
        { "id": "a4", "kind": "data", "label": "Total", "value": "$37.50", "exact": true }
      ]
    }
  ]
}

An account attachment names a saved sign-in by its account name: { "id": "a5", "kind": "account", "role": "store-owner", "exact": false }. Sign-ins are saved in the dashboard, under the project's Sign-ins, so the prompt asks you for their names instead of creating them.

Rules that keep a migration honest

• Outcomes, not instructions. #btn-submit-2 and waitForSelector say nothing about the product. "The order is listed as paid" does.
• One test, one test case. Don't merge tests, and don't add steps the test didn't check.
• Exact only for what the test is about. An asserted price, a coupon that must apply, or a phone number that must be refused is Exact. Everything else is test data: if the product says a value is taken, the agent uses a fresh one.
• No secrets in steps. Credentials become saved sign-ins or secret environment values. Secrets are filled by reference, and the agent never sees them.

Framework guides

• Playwright
• Cypress
• Puppeteer
• Selenium
• Appium
• Maestro
• mabl