How to Automate Email Testing in Playwright and Cypress

The Gap in Most End-to-End Suites

End-to-end tests happily click through forms and assert on pages, but they tend to stop at the inbox door. Registration, password reset, magic-link login, and order confirmation all depend on an email that arrives out of band, and most suites either skip those steps or mock them at the application layer. Mocking proves your code calls the mail function; it does not prove that a real message, with a real link or code, actually arrives and works. A temporary email service closes that gap by giving your tests a real inbox they can read programmatically.

The Pattern in Plain Terms

Every email test follows the same shape regardless of framework:

1. Create a fresh temporary inbox and obtain its address.
2. Drive your application to trigger the email, for example by submitting a registration form with that address.
3. Poll the inbox until the expected message arrives, with a sensible timeout.
4. Extract what you need from the message: a verification link, a one-time code, or specific body text.
5. Use it to complete the flow, then assert the application reached the expected state.

Keeping this shape in mind makes the framework-specific code easy to read.

A Helper for Polling

The one piece worth writing carefully is the poll-with-timeout helper, because email arrival is asynchronous and variable. A simple version waits between attempts and gives up after a maximum number of tries:

• Request the messages for your inbox from the temp email API.
• If a message matching your criteria is present, return it.
• Otherwise wait a couple of seconds and try again, up to a maximum total wait.
• If nothing arrives in time, fail the test with a clear message rather than hanging.

A total timeout in the range of 30 to 60 seconds absorbs normal delivery variation without making a failing test slow to report.

Using It in Playwright

Playwright runs in Node, so your test can call the temp email API with the same fetch you would use anywhere. Create the inbox in a setup step, use the address in the page interactions, then await your polling helper to retrieve the message. Because Playwright already encourages async/await, the email step reads as just another awaited call between page actions. Pull the verification link out of the message body and navigate to it with page.goto, or extract the numeric code and type it into the confirmation field.

Using It in Cypress

Cypress runs commands in the browser, so network calls to a third-party API are best wrapped in cy.request or moved into a cy.task that executes in Node. A common approach is to write a task that creates an inbox and another that polls for a message, then call them from the test with cy.task. Keep the polling logic in Node rather than chaining many cy.wait calls, which keeps the test readable and the retries reliable. Once you have the message, use cy.visit on the extracted link or type the code into the form as usual.

Extracting Codes Reliably

Pulling a one-time code from an email body is the fiddliest part, because the surrounding wording varies between services. A robust approach uses a ranked list of patterns, from most specific to least. Start by looking for a code that follows an explicit label such as "code" or "OTP", fall back to a code that follows an instruction like "enter" or "use", and only as a last resort match any standalone group of digits of the expected length. Returning the first match from the most specific pattern avoids grabbing an unrelated number such as a year or an order total.

Keeping Tests Fast and Stable

A few habits keep an email-driven suite from becoming flaky. Create a new inbox per test so messages never bleed between cases and tests can run in parallel. Prefer a service with webhook support if your runner can receive callbacks, since reacting to a pushed message is faster and steadier than polling. Set a generous but bounded timeout so a slow mail server does not fail an otherwise healthy test, and store any API key in your runner's secrets manager rather than in the repository.

Why It Is Worth Doing

Email steps are exactly the parts of a user journey that break silently in production: a templating change swallows the code, a link points at the wrong environment, a provider switch drops messages. Testing them against a real inbox catches these failures before users do. With a small polling helper and a temporary email API, the inbox stops being a blind spot and becomes just another assertion in your end-to-end suite.