AI E2E testing: the tool surface, not the script.

The label covers two different architectures that get marketed the same way. The first architecture treats AI as a code generator: the model writes a .spec.ts file against a framework like Playwright or Cypress, then a normal runner executes the file. Maintenance shifts from hand-writing selectors to reviewing AI-written selectors; nothing about the runtime changes. The second architecture treats AI as the runner: the model is given a tool surface (navigate, click, type, assert), receives an accessibility-tree snapshot of the page, and decides on each turn what to call next. No .spec.ts file is ever written. Assrt is the second kind. The distinction matters because only the second kind adapts to UI drift at the moment of the click, rather than at the next regression run.

Assrt defines 18 tools in the TOOLS array at assrt-mcp/src/core/agent.ts lines 16 to 196: 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, and wait_for_stable. That is the whole API the model sees. It cannot invent a nineteenth, because every call goes through the MCP tool schema and the server rejects names it does not know. The practical consequence for reviewers: 'can the AI call a hallucinated Playwright method?' is not a question you have to ask. The schema mechanically prevents it.

At agent.ts line 7, Assrt sets MAX_STEPS_PER_SCENARIO = Infinity, and at line 8 sets MAX_CONVERSATION_TURNS = Infinity. Most tools with an AI in the loop pick a hard cap: 25 steps, 50 turns, whatever feels safe. A cap is a quiet failure mode; a long or recovery-heavy scenario hits it, the test reports FAILED with an 'out of steps' summary, and the human has to guess whether the test was right or the cap was too tight. By leaving it uncapped, Assrt lets the agent exhaust its own budget naturally: it either calls complete_scenario, runs out of API retries, or the run timeout at the browser layer kicks in. The model decides when the scenario is done, not a hard-coded constant. If you want a cap, you set it at the CLI or CI layer.

Every time the agent calls navigate() inside a scenario, Assrt also calls queueDiscoverPage() for that URL (agent.ts line 775). The queue is drained by flushDiscovery() (lines 564 to 583) which runs up to MAX_CONCURRENT_DISCOVERIES = 3 simultaneous LLM calls to generate 1-2 test cases for each newly-seen page, using a separate short prompt (DISCOVERY_SYSTEM_PROMPT, line 256). A cap at MAX_DISCOVERED_PAGES = 20 stops it from consuming the run. So while your explicit plan is running on page A, three background calls are examining pages B, C, and D and proposing #Case blocks for them. The results arrive on the emit stream as page_discovered and discovered_cases_complete events. This is how one 30-second test run can surface 8-10 candidate test cases for adjacent flows without you writing them.

Every snapshot call returns the page as an accessibility tree where each focusable element has an opaque id like e5 or e12. When the agent clicks, it passes ref='e5' and Playwright MCP resolves that id on the live page. Three consequences. First, there is no selector string for the model to hallucinate; if an element is not in the snapshot, the agent cannot click it. Second, UI redesigns that change class names do not break the test, because the ref is rebound on each snapshot call. Third, assertion evidence is human-readable: a trace reads 'click e5 (Submit order button)' rather than 'click div:nth-child(3) > button.v2'. The SYSTEM_PROMPT at line 198 enforces 'ALWAYS call snapshot FIRST' because stale refs are the only way for this scheme to fail.

Traditional Playwright tests pick a number: wait 2 seconds after clicking submit, wait 500ms for an animation, wait 10 seconds for the API. Too short and you get flake; too long and your suite takes an hour. wait_for_stable (agent.ts lines 956 to 1009) injects a MutationObserver into the page, counts DOM mutations in __assrt_mutations, and returns as soon as N consecutive seconds pass without a new mutation (default N is 2, max wait is 30). It adapts to the actual page: a fast login returns in 2 seconds, a slow chat response returns when the streaming stops. No magic number. The cleanup after the wait disconnects the observer and deletes the window globals, so your app sees no lingering overlay.

Every turn sends the Anthropic API a list of messages that includes the latest accessibility snapshot (text, up to 3000 chars) plus a JPEG screenshot of the current viewport. After every tool call except snapshot, wait, assert, and a few other non-visual ones (see the exclusion list at line 1024), the agent automatically captures a fresh screenshot so the next turn has up-to-date vision. The system prompt tells the model to prefer refs from the snapshot over visual matching, but the screenshot is there as a correctness check (the tree can be ambiguous, the image is not). Sliding window logic at lines 1064 to 1080 keeps the conversation from growing unboundedly by trimming at assistant/model boundaries, so a long scenario does not blow the context.

The preflightUrl() method at agent.ts line 518 does a HEAD/GET check with an 8-second timeout before Assrt even launches Chrome. A wedged dev server fails fast with an actionable 'Target URL did not respond within 8000ms' error, instead of burning time on a Chrome launch and then surfacing an opaque 'MCP client not connected' three minutes later. Once the run is going, the navigate wrapper at line 443 applies a 30-second timeout per navigation for the same reason. These are not nice-to-haves; without them, a single misbehaving server turns a 30-second test into a 3-minute hang plus a confusing error message.

Yes, in the same plan, without a Mailosaur account. create_temp_email spins up a disposable inbox via the DisposableEmail class at core/email.ts (a call to an ephemeral-email service). wait_for_verification_code polls the inbox for up to 120 seconds and parses the OTP out. If the OTP input is the common split-across-six-fields pattern, the system prompt at line 234 instructs the agent to use evaluate() with a specific ClipboardEvent + DataTransfer expression that pastes all digits at once; typing into each field separately breaks on most React OTP components. That exact expression is hard-coded in the system prompt so the model does not have to rediscover the trick each run.

Self-healing is a patch on top of a selector-based stack: the framework tries alternate selectors when the primary one breaks. Assrt removes the selector layer entirely, which is a different architecture. Momentic and QA Wolf are hosted SaaS products with their own runtimes, closed test formats, and per-seat pricing that tends to sit in the thousands per month. Assrt is npm-installed, MIT-licensed, runs on your machine or your CI, and the tests are plain Markdown files you commit to your repo. Same category on a shelf, very different cost and portability profile. The code is at github.com/assrt-ai/assrt-mcp and you can read every file yourself.