How to test password reset emails end to end

A password reset test should prove that a user can recover access, from requesting the email to signing in with a new password. Checking that the application called its mail provider only covers part of that journey. Agent Temp Mail gives the test a real receiving inbox so the email step can be part of the same automated run.

Prepare an account and a dedicated inbox

Create a fresh Agent Temp Mail identity for the test and use its address when creating your test account. Keep the identity available until the entire recovery flow finishes. A separate identity for each test keeps recovery messages from different runs apart, including when several workers run at once.

Run this against an application you control, using an environment that can send real email. Record the account's original password in the test fixture and choose a different replacement. Make sure the initial account creation and verification have completed before starting recovery.

Receive the reset message

1. Record the current time immediately before requesting a reset.
2. Submit the account's email address through the password recovery form.
3. Wait for a message received after that timestamp from your expected sender.
4. Fetch the complete message and inspect the candidate links.

Agent Temp Mail exposes received messages and extracted link candidates, which gives your test structured data to work with. Select the link that matches your application's reset route. Parse it as a URL and check its exact origin before opening it. This catches a staging template accidentally pointing at production, as well as an unrelated link being selected from the email footer.

Assert the outcome in the application

Open the reset link, submit the replacement password, and confirm the application reports success. Then start a new browser session and sign in with that password. A fresh session matters: an existing login cookie can make a broken recovery flow appear to work.

Also verify that the original password no longer grants access. If your application promises single-use reset tokens, revisit the same link and assert the documented used-token behavior. Test token expiry separately using the application's configured lifetime; mailbox message availability and reset-token validity are different things.

Make failures easy to diagnose

Give email delivery a bounded timeout and report which stage failed: no message arrived, the expected link was missing, the destination was wrong, or the application rejected the reset. Keep tokens, private keys, and complete reset URLs out of shared test logs.

Agent Temp Mail makes the receiving side straightforward: your test owns an inbox identity and reads the messages associated with it. That lets the assertions focus on what matters to your users, a recovery journey that actually restores access.