Email Testing

<objective> Email-dependent flows fail silently: a test that "signs up and clicks confirm" by calling the confirm endpoint directly never proves the email was generated, addressed, templated, and linkable. This skill captures the real email, waits for it without a fixed sleep, extracts the OTP or link from the body with an anchored regex, and completes the flow — so a broken template, an unsigned token, or a wrong-recipient bug actually fails the test. It also keeps deliverability (SPF/DKIM/DMARC) in a separate non-blocking suite so a DNS problem never reds your functional gate. </objective>

Quick Route

Discovery Questions

Check .agents/qa-project-context.md first — if it exists, use it and skip anything answered there.

• Where does the email need to be received? Local capture (Mailpit) covers most functional flows for free. A real, externally-deliverable address (staging, a third- party ESP, real DNS) means a hosted inbox (Mailosaur / MailSlurp). This is the single biggest tool-selection driver.
• How parallel is the suite? High parallelism makes "the latest email" ambiguous — you need per-test unique addresses or per-test inboxes, not a shared mailbox.
• Which flows? Signup confirmation, password reset, magic-link login, OTP/MFA, notification emails — they share one shape (capture, extract, complete) but differ in what you extract (link vs 6-digit code).
• Is deliverability in scope? "Lands in inbox / passes SPF, DKIM, DMARC" is a separate non-blocking suite, not part of the functional OTP test. Decide upfront.
• Local-only preview, or CI assertions? Previewing a template during dev is Ethereal; asserting in CI is Mailpit/Mailosaur/MailSlurp. Don't confuse the two.

Core Principles

1. Capture the real email; never shortcut past it. Calling the reset endpoint directly or hardcoding a token skips the exact integration the test exists to cover — templating, recipient resolution, link generation, token signing. Submit on the UI, read the inbox.

1. Poll, never sleep. Email arrival is asynchronous. A fixed waitForTimeout is either too short (flake) or too slow (wasted minutes) and is the #1 cause of flaky email tests. Use expect.poll / .toPass against /api/v1/messages, or a built-in waiter (messages.get, waitForLatestEmail) that already polls for you.

1. One unique recipient per test. Two parallel tests both reading "the latest signup email" grab each other's mail. Make every test's address unique (plus-addressing or a per-test inbox) and filter by recipient when reading. Clearing the inbox between tests does NOT survive parallelism.

1. Extract from the body with an anchored regex, guarded. Pull the OTP / link from the email body (message.Text / message.HTML), not the live page. Use \d{6} / .match( and assert the match is not null — a missing code must fail loudly, not become undefined.

1. Assert content, not existence. "An email arrived" is a weak assertion. Check the subject, the from address, and that links point to the right domain. Wrong-template and wrong-link bugs only surface if you assert on content.

1. Deliverability is a separate, non-blocking suite. SPF/DKIM/DMARC come from a real receiving server's authentication, never from the body text — and they must not block the functional flow tests.

Capture-inbox decision tree

Pick the cheapest tool that can actually receive your mail. Default to Mailpit for local + CI functional tests; reach for a hosted inbox only when you need real addresses or high-parallelism isolation.

For the budget signup-flow case (local + GitHub Actions, self-host fine): use Mailpit — a single binary / docker image with a free, open-source REST API at :8025. If you later need a real deliverable address, graduate that suite to Mailosaur or MailSlurp (hosted inboxes with real addresses). Do not "just check the database instead of the email" — that proves the row was written, not that the email was sent, addressed, and linkable.

Avoid: MailHog — archived/unmaintained since 2020; Mailpit is its drop-in replacement (same ports, compatible API), verified mid-2026. Also skip smtp4dev / Papercut for new suites — Mailpit's API and full-text search are better for automated assertions.

See references/mailpit-playwright.md for the docker-compose, the polling helper, and the extraction utilities; references/hosted-inboxes.md for Mailosaur / MailSlurp / Ethereal.

Polling an inbox (Mailpit)

Read the list endpoint with Playwright's request fixture, find the message addressed to this test's recipient, then fetch the full body by ID. Use expect.poll with a timeout and intervals — it retries until a match appears, so fast inboxes resolve instantly and slow ones still pass.

// `request` is the Playwright APIRequestContext fixture; plain fetch() works too.
await expect.poll(async () => {
  const res = await request.get(`http://localhost:8025/api/v1/messages?query=to:${encodeURIComponent(to)}`);
  const { messages } = await res.json();
  return messages.find((m) => m.To.some((t) => t.Address === to))?.ID ?? null;
}, { timeout: 30_000, intervals: [500, 1_000, 2_000] }).not.toBeNull();
// then: request.get(`http://localhost:8025/api/v1/message/${id}`) → { Text, HTML, Subject, From, To }

The query=to: filter plus the .find on the recipient is what makes parallel tests deterministic. Never take messages[0] / messages.at(-1) (newest overall) with no recipient filter. Full helper in references/mailpit-playwright.md.

Extracting OTPs and links

Match against the email body, anchored, with a null guard:

const otp = body.match(/\b(\d{6})\b/)?.[1];
expect(otp, 'no OTP in email body').toBeTruthy();   // throw / fail if null

const link = body.match(/https?:\/\/\S*(?:verify|confirm|reset|token=)\S*/i)?.[0];
if (!link) throw new Error('no verification link in email body');

Do NOT slice by index (body.split(' ')[3], substring(0, 6), indexOf('code')) — those break the moment the template changes a word. Do NOT read innerText of the live page when you mean the email body. If a 6-digit code could collide with other numbers, anchor on the