Learn e2e testing by learning eighteen tools, not a framework.

Every top result for 'e2e testing tutorial' teaches you to install a framework (Playwright, Cypress, Selenium, WebdriverIO) and then write selectors against the DOM. This tutorial has zero framework import. The entire vocabulary you learn is eighteen named tools in a TypeScript array at /Users/matthewdi/assrt-mcp/src/core/agent.ts line 16. The plan you write is a markdown file with #Case N: headings and English sentences. A Playwright MCP server is still under the hood, but you never call it directly and you never write a selector; the agent resolves each sentence against a fresh accessibility tree at runtime.

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. They are declared in /Users/matthewdi/assrt-mcp/src/core/agent.ts between lines 16 and 196. That file is the canonical reference; if you add a nineteenth tool there, every #Case in the world becomes able to use it without a plan change.

Three pieces. First, create_temp_email allocates a disposable inbox and saves the address for the run. Second, wait_for_verification_code polls that inbox every three seconds for up to sixty (or up to one-twenty if you ask), extracts the numeric code with a regex, and returns it. Third, if the verification UI uses the common split-digit layout (six single-character <input maxlength=1> fields), the agent is instructed to paste the code in a single DataTransfer ClipboardEvent rather than typing one digit per field. The exact expression lives in the system prompt at agent.ts lines 234 to 236 and is worth reading even if you never use Assrt.

Typing one digit per input races with the widget's autoadvance handler. Most OTP widgets move focus on input; typing 'A' then 'B' often ends up as 'A_B' because the second keystroke lands after focus jumped. Pasting via ClipboardEvent on the container fires one onPaste on the React or Vue owner, which runs the widget's single canonical fill path. This works for the large majority of OTP components shipping today. It is the one thing in this entire tutorial you will copy into non-Assrt code, which is why it is linked from the anchor above.

It injects a MutationObserver into document.body that increments window.__assrt_mutations on every childList, subtree, and characterData change. The agent then polls that counter every 500ms. When the counter has not changed for stable_seconds in a row (default two), the wait returns. There is a timeout_seconds ceiling (default thirty). The implementation is in agent.ts lines 962-994. The point is that you never need to write waitForSelector('.loading-done') again; any DOM quietude satisfies it, which is what 'the page is done' actually means across a diverse UI.

Yes. http_request is a first-class tool at agent.ts:171. It supports GET, POST, PUT, DELETE, custom headers, a JSON body, and a 30s timeout. Responses over 4000 characters are truncated. The canonical example: after your webapp claims to have sent a Telegram message, the same #Case calls http_request with https://api.telegram.org/bot<token>/getUpdates and asserts the message is in the list. This collapses the usual two-suite setup (e2e for the UI + integration tests for the webhook) into one scenario.

The parser at agent.ts lines 620-631 splits the plan on a regex that matches #Case, #Scenario, or #Test followed by a number and a colon (or period). Each block becomes a scenario with the rest of the block as its steps. Inside one run, all scenarios share the same browser session: cookies, local storage, auth, and URL state carry over. That is deliberate. It lets you write #Case 1 sign up, then #Case 2 create a project, then #Case 3 invite a teammate, with each case building on the last, instead of logging in three times.

No. Two mechanisms take the place of the usual console-log-and-rerun loop. First, every run can record a video with --video, saved to /tmp/assrt/<run>/video.webm; the default is to auto-open the player when the run finishes. Second, assrt_diagnose takes the failure report plus the live page and returns a corrected #Case in prose, with Root Cause, Analysis, and Recommended Fix sections. The key line is that the diagnosis output is markdown you paste back into plan.md, not a selector patch you paste into a .spec.ts.

It sits on top of Playwright MCP. @assrt-ai/assrt spawns a Playwright MCP server over stdio and calls browser_navigate, browser_click, browser_type, browser_snapshot, and friends underneath the eighteen tool names you see. The difference is what you write. You write #Case blocks, not .spec.ts files; the agent writes the Playwright calls. If you are already invested in Playwright, nothing is thrown away; you are adding a prose layer above the existing one.

Open three files. /Users/matthewdi/assrt-mcp/src/core/agent.ts line 16 for the TOOLS array and line 196 for where it ends. Lines 234-236 for the OTP paste expression. Lines 620-631 for the scenario regex. Lines 962-994 for the wait_for_stable MutationObserver loop. Every non-trivial claim in this tutorial has a file-and-line anchor in that one source file so you can diff it against this page and flag anything that has drifted.