Test Passwordless Login Without Inbox Chaos
Passwordless login looks easy in a demo. A user enters an email, gets a magic link, and logs in.
In staging, this flow breaks. Links land in shared inboxes or old email aliases. Testing becomes a mess.
You must treat passwordless auth as one single system. You need to test the JavaScript client, the Node.js backend, the email delivery, and the final session.
If you skip the inbox, your API tests might pass while the user experience fails.
Common failures include:
- The backend sends two links after a retry.
- The email points to the wrong environment host.
- An old link works longer than it should.
- The frontend marks the user as logged in before the cookie sets.
Use an isolated inbox for every test run. This keeps your data clean and your debugging fast. If three tests use one inbox, you cannot find the error.
Follow this workflow:
- Trigger the login from your UI or an end-to-end test.
- Let Node.js send the link through your staging path.
- Capture the message in a fresh, isolated inbox.
- Open the newest link in the same browser session.
- Verify the authenticated state.
A good test does more than check if an email arrived. Check these steps in order:
- The login request returns a neutral success response.
- Exactly one fresh magic link exists.
- The link host matches your staging domain.
- The token starts a valid session.
- Reusing the same link fails.
- The app updates the UI without a manual refresh.
On the backend, attach a correlation ID to your logs. This helps you track a request from creation to the final session.
Do not replace all your tests with email-driven tests. Use fast unit tests for logic and use this inbox path for your staging suite.
Use this checklist before you ship:
- A login request creates only one active link.
- The newest email is easy to parse in staging.
- The link signs the user in on the correct host.
- The link cannot be used twice.
- Logout and re-login produce a clean new token.