How to test automation when the agent writes the test, not you.

It means the unit of automation moved up one level. In 2019 you automated the clicks: you wrote Selenium or Playwright code that drove the browser. In 2026 you automate the plan: you write a sentence like 'Click Sign In, use a disposable email, verify the dashboard heading loads' and a coding agent picks the right browser tools to execute it. Assrt is a concrete example: its agent exposes exactly 18 tools (navigate, snapshot, click, type_text, select_option, scroll, press_key, wait, screenshot, evaluate, create_temp_email, wait_for_verification_code, check_email_inbox, assert, complete_scenario, suggest_improvement, http_request, wait_for_stable) and chooses among them per step. The Playwright code still runs underneath, the agent just writes it for you at runtime.

Gherkin and YAML test DSLs are schemas that a human authors and a parser compiles. The #Case format is a prompt that an agent interprets. Concretely, the plan file at /tmp/assrt/scenario.md contains blocks like '#Case 1: Homepage loads' followed by 3-5 lines of plain imperative English. The PLAN_SYSTEM_PROMPT in assrt-mcp/src/mcp/server.ts line 219 pins the shape and tells the agent what its vocabulary is; the agent then picks concrete tools per step. You never learn a syntax. If a non-engineer reads the file on GitHub they can edit it, and the next run uses the edited text. That is not possible with a compiled Given/When/Then tree.

Assrt has a tool called wait_for_stable. When the agent calls it, the code at agent.ts lines 911-921 executes `window.__assrt_observer = new MutationObserver(...)` inside the page under test, then polls `window.__assrt_mutations` every 500ms. When the count stays flat for the configured stable window (2 seconds by default, 10 max), the action returns with an elapsed time and the total mutation count. This is different from every Selenium wait helper you have used. It is not `waitForElement`, it is not `sleep(2000)`, it is a live count of DOM mutations going to zero. The observer is cleaned up in a finally-style cleanup: `window.__assrt_observer.disconnect(); delete window.__assrt_mutations;` so the page is left exactly as it was.

The agent has two tools for this: create_temp_email and wait_for_verification_code. When it sees an email field in the signup form, the SYSTEM_PROMPT in agent.ts tells it to call create_temp_email first, use the returned address in the form, submit, then call wait_for_verification_code with a timeout in seconds. A disposable inbox is created on demand and polled for up to 120 seconds. If the OTP is split across single-character fields (common for six-digit codes), the agent is instructed to use `evaluate` with a specific DataTransfer paste expression instead of typing one character at a time, because typing per-field triggers controlled-input bugs in many React implementations. That exact expression lives inline in the system prompt so the agent never invents its own variant.

Yes, that is what the http_request tool is for. It is a 30-second timed fetch wrapper the agent can call with a URL, method, headers, and JSON body. After the agent does something in the UI, like 'Connect Telegram' or 'Publish post', it can call http_request against the external API (Telegram Bot API, Slack Web API, a staging webhook receiver) to confirm the event arrived. This closes a gap that every traditional test-automation guide skirts: the app can look like it worked while the backend fire-and-forget job silently failed. http_request lets a single scenario cross that boundary without leaving the test runner.

The plan lives at /tmp/assrt/scenario.md. The companion scenario-files.ts starts an fs.watch on that file after each test run, debounced by one second. Editing the file from your text editor, from the agent chat, or from a CI step all trigger the same sync back to central storage. Because it is a real file, a human can open it, change '#Case 3: Checkout requires email' to include a second assertion, save, and the next assrt_test run uses the new text. You do not need a UI to edit the test. grep, sed, and git are fine.

Under the hood, the agent wraps @playwright/mcp, the Playwright MCP server Microsoft maintains. When the agent calls its `click` tool with a description and a ref, that gets translated into real Playwright commands against a real browser process. The ref values (e.g. `ref=e5`) come from Playwright MCP snapshots of the accessibility tree. So the pipeline is: Markdown plan -> agent tool call -> Playwright MCP call -> Playwright browser driver -> Chrome. The test is portable in the sense that if you exported the run, you would have a Playwright trace, not a proprietary YAML format.

assrt_plan navigates to a URL, takes a snapshot of the accessibility tree, and asks a small model to generate 5-8 #Case entries in the same Markdown format assrt_test consumes. The generated plan lands at /tmp/assrt/scenario.md, you review it, keep what is useful, and then assrt_test executes. It is not magic, the model just proposes likely flows based on the buttons and inputs actually visible on the page, under the rule 'each case must be completable in 3-4 actions max, no login/signup unless a form is visible, no CSS or performance tests'. Treat the output as a starting point, not a finished suite.