Test Passwordless Login Without Inbox Chaos
Passwordless login looks easy in a demo. A user enters an email. A magic link arrives. The session starts.
In staging, this flow gets messy. Links land in shared inboxes or old aliases. This creates noise.
You must treat passwordless auth as one full system. You need to test the JavaScript client, the Node.js backend, the email delivery, and the session. If you skip the inbox, you might ship a broken flow even if your API tests pass.
Common failures include:
- The backend sends two links after a retry.
- The email points to the wrong host.
- An old link works longer than it should.
- The frontend marks a user as signed in before the cookie sets.
Use an isolated inbox for every test run. This prevents testing data from leaking into team mailboxes. Use disposable email services for staging to keep runs separate.
Isolation makes debugging easy. If a test fails, you should see one inbox and one user journey. You should know exactly which message belongs to which build.
A good test checks these steps in order:
- The login request succeeds without revealing if an account exists.
- Exactly one fresh magic-link arrives.
- The link host matches your staging domain.
- The link starts a valid session.
- Reusing the same link fails.
- The app updates navigation without a manual refresh.
On the Node.js side, attach a correlation ID to your logs. Use it from the request to the email send and the final session. This helps you find bugs when emails are slow or duplicated.
Do not replace all your tests with email tests. Use fast unit tests for token logic and session rules. Use the email path to prove the real user experience works.
Checklist before you ship:
- One login request creates only one active link.
- The newest email is easy to parse in staging.
- The link works on the correct host.
- The link cannot be reused.
- Logout and re-login create a clean new token.