QA automation tutorial: automating the signup + OTP flow every other guide skips

Because it is genuinely the hardest part of a real test suite to automate, and it is easier to write a tutorial about login with a fixture user. The signup flow usually involves a real mail server, a verification email, a time-sensitive code, a cross-session paste, and a callback URL. Most tutorials hand-wave this with 'use a test fixture account' or 'mock your email provider', and the reader walks away with a toy test that collapses on the first production use case. This tutorial fixes that gap by leaning on three Assrt tools (create_temp_email, wait_for_verification_code, check_email_inbox) that wrap a real disposable mailbox and a deterministic regex code extractor. Every step is checkable: the tools are defined in assrt-mcp/src/core/agent.ts between lines 115 and 130, and the regex patterns live in assrt-mcp/src/core/email.ts between lines 101 and 109.

A disposable email is a temporary inbox at a provider like temp-mail.io that accepts any message addressed to it and exposes those messages over an HTTP API. You do not run a mail server, you do not create a Gmail account, you do not have to clean up state between runs. Assrt calls `POST https://api.internal.temp-mail.io/api/v3/email/new` (email.ts line 44) with `{ min_name_length: 10, max_name_length: 10 }` so every run gets a unique 10-character prefix like aQ9mZ2cP7r@1secmail.net. You type that address into the signup form, your app sends the verification email, the mailbox receives it, and the tutorial reads it back with `GET /email/{address}/messages`. No SMTP stub, no fixture pool to maintain.

email.ts lines 101-109 run seven regex patterns in priority order against the plain-text body (HTML emails are stripped first). The patterns are, in order: /(?:code|Code|CODE)[:\s]+(\d{4,8})/, /(?:verification|Verification)[:\s]+(\d{4,8})/, /(?:OTP|otp)[:\s]+(\d{4,8})/, /(?:pin|PIN|Pin)[:\s]+(\d{4,8})/, then raw 6-digit, 4-digit, and 8-digit number matches as fallbacks. The first pattern that matches wins, so a well-formatted email like 'Your code: 482197' resolves before the extractor ever considers random 6-digit numbers elsewhere in the body. If no pattern matches, the full body is returned so the agent can reason about the content instead of failing hard.

create_temp_email creates a new disposable address and stores it on the agent as `this.tempEmail` (agent.ts line 801). wait_for_verification_code polls the inbox every 3000ms for up to 60 seconds by default, capped at 120000ms by Math.min on agent.ts line 810, and returns `{ code, from, subject, body }`. check_email_inbox is a raw fetch of all current messages, useful when you want to assert on a welcome email that is not a verification code. You call them by name inside a plain-English `#Case` block, exactly as you would tell a careful junior tester: 'Call create_temp_email, type that address into the Email field, submit, then call wait_for_verification_code and type the code into the OTP field.'

It runs on top of Playwright. Assrt spawns @playwright/mcp under the hood, which is the official Playwright MCP server. The agent still drives a real Chromium, Firefox, or WebKit process via real Playwright APIs, and every interaction (navigate, click, type, snapshot) is a real Playwright command. The QA automation tutorial value-add is that you write the plan as English, not as code, and the agent translates the English into Playwright calls using the 18 tools defined in agent.ts between lines 16 and 196. If you already have a Playwright suite, the two can live side by side: keep the high-traffic tests in TypeScript, and use plain-English `#Case` blocks for flows that would otherwise never get automated (like signup + OTP).

For a typical SaaS signup flow with a 6-digit email code, expect about 8 to 14 seconds total. Breakdown: navigate and snapshot (1-2s), type email and password (1s each), click sign up (1-2s), create_temp_email and type it (usually already cached, under 1s), wait_for_verification_code polls every 3 seconds and most providers deliver in 3-6 seconds, type the code (1s), submit (1-2s), wait for the success page and assert. The poll interval of 3000ms is a deliberate cost-vs-latency trade: tight enough to catch fast providers, wide enough not to rate-limit temp-mail.io during a dozen parallel tests.

The waitForVerificationCode method at email.ts line 82 returns null after the timeout expires. Back in agent.ts line 822-827, the tool handler converts that into a failed step with description 'Verification email timeout' and records it in the scenario result. The scenario is not aborted automatically; the agent sees the failure in its conversation history and can call suggest_improvement to log it as a product bug (maybe your transactional email provider is down), or retry with a fresh mailbox. In CI, you treat the failed scenario like any other red test: the run directory at /tmp/assrt/<runId>/ still contains the video, screenshots, and events.json so a human can review what the agent was waiting for.

Yes, but not through the bundled tools. The DisposableEmail class in email.ts is coupled to the temp-mail.io REST API (BASE constant on line 9). If you need to swap providers, fork that file and implement the same three methods: create(), getMessages(), and waitForVerificationCode(). The agent.ts handlers at lines 800-842 only use the public interface, so any object that returns the same shape works. For most tutorials and smoke tests temp-mail.io is fine; the reason to swap is typically compliance (you want an inbox on your own infra) or testing your own transactional templates with your own allow-list.

Three ways. First, the plan lives in your repo as scenario.md, not in a vendor dashboard, so you keep it when you cancel. Second, the runner is npx assrt-mcp, so nothing is rented. Third, the disposable-email integration is open-source code you can read, which is how you know the regex patterns, the polling interval, and the 10-character prefix rule in this tutorial are real. A commercial platform that builds the same feature behind a closed dashboard is selling you confidence in a black box. A tutorial that leans on open-source tools can cite email.ts line 49 for the prefix length and agent.ts line 810 for the timeout ceiling, and you can verify both in about 30 seconds.

Yes. The disposable-email flow is pure HTTP, so it runs the same on a CI worker as it does on your laptop. Playwright MCP launches Chromium headless by default, and temp-mail.io does not care whether the request comes from GitHub Actions or your terminal. The one thing to remember is that your LLM key needs to be available as an environment variable (ANTHROPIC_API_KEY or GEMINI_API_KEY); Assrt reads from keychain in dev and from env in CI. Upload /tmp/assrt/<runId>/ as a workflow artifact and a failing run is still inspectable from the Actions page.

Out of the box, no. The three disposable tools are all email-flavored. For SMS you can use the http_request tool (agent.ts line 172) to poll a service like Twilio, a disposable SMS provider, or your own /debug endpoint that surfaces recent codes. Write the plan as 'Poll https://myservice.example/dev/last-sms and assert the body contains a 6-digit code, then type that code into the OTP field.' The agent will call http_request, pull the JSON, extract the code with a prompt-level regex, and continue. The pattern is the same as email; only the source of the code changes.

People who have already done 'my first Playwright test' once and want to automate the flow that actually matters in production: a new user signing up, verifying their email, and landing on the dashboard. It is useful for small teams that cannot justify a Testim subscription, for solo founders that need to protect their signup funnel, for staff engineers that want a regression guard on auth changes without paying a vendor, and for anyone who has tried to mock a mail server in CI and lost a week to it.