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 over a free JSON API, 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
- Named inbox + REST API. Choose any address, send mail to it, read it back with one GET. No account, no provisioning — ideal for CI. The API recipe is in Tempx for Developers.
- 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.
Example: assert a verification code in one line
# Send your signup mail to signup-test-17@tempx.uk, then:
curl -s "https://tempx.uk/api/inbox?address=signup-test-17@tempx.uk" | jq -r '.messages[0].preview'Each message carries from, subject, a text preview and timestamps, so the assertion stays in your usual test framework. 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.