Email testing: assert on the messages your app sends
Email testing is the practice of treating email as part of your test suite instead of a leap of faith. The messages your app sends — signup confirmations, one-time codes, password resets, receipts — gate your most critical flows, and they break quietly. Tempx gives every test run a real, disposable inbox: mail arrives in seconds, the inbox is readable in the web app, the browser extensions or programmatically, and everything deletes itself. Nothing is ever delivered to a real person.
What to test
| Flow | Worth asserting |
|---|---|
| Signup confirmation | Mail arrives within your timeout; the link matches your expected host and token shape. |
| OTP / login codes | The code is present, matches your format (e.g. 6 digits), and a fresh request invalidates the old one. |
| Password reset | The token is single-use, expires, and the reset actually completes end to end. |
| Transactional & notification mail | Subject and template render the live data (order number, name), not placeholder text. |
| Staging sanity | Staging senders really point at staging — no customer ever receives a test run. |
Three ways to run it on Tempx
- SMTP capture for the sending side. Point your app's mailer at the capture-only gateway and inspect what it “sends”. Covered in SMTP testing.
- Hand the loop to an AI agent. Over MCP, an agent can wait for the message and check the flow itself — see Tempx for AI Agents.
- Watch it like a human. The web inbox and the Chrome/Firefox extensions show every arriving message live — the fastest sanity-check while you build the flow.
Example: wait for the code instead of polling for it
// over MCP: block until the message exists, then read it
const msg = await tempx.callTool("wait_for_email", {
since: "2 minutes ago",
subjectRe: "verify|confirmation",
});
const code = msg.text.match(/[0-9]{6}/)?.[0];Each message carries from, subject, a text preview and timestamps, so the assertion stays in your usual test framework — and for a human in the loop, the same message shows up live in the web inbox and the browser extensions. For the full patterns — OTP extraction, retry windows, parallel-worker naming — see the guides on testing email verification and testing OTP emails.
Common failure modes worth testing for
- Timing. Decide what “arrived” means: poll with a deadline rather than sleeping a fixed number of seconds.
- Isolation. Parallel test runs share nothing if each run uses its own inbox name.
- Retention. Inboxes auto-delete (1 hour for private random inboxes, up to 7 days for named ones) — fetch and assert inside the test, not afterwards.