A magic-link login is really four things: a form, an email, a token and a signed-in session. They fail separately, so they're worth testing separately. A page that says "Check your inbox" tells you the form worked. It doesn't tell you the email arrived or that the link will still work when someone clicks it.
Split the handoff
| Part | What can go wrong | Where to test it |
|---|---|---|
| Request form | Validation, wrong confirmation message | Browser test |
| Email delivery | Message never sent, wrong recipient | Email test harness |
| Token | Expired, already used, wrong account | Authentication tests |
| Signed-in app | Wrong account state, missing permissions | Browser test with a prepared account |
Keeping these apart makes a failure easier to act on. The browser test covers the form, and the email or authentication test covers the handoff.
Watch the token
The test needs a fresh token with a known lifetime. A used or expired link can make a test fail for the wrong reason, so don't reuse single-use links across tests. Test expiry and one-time use at the authentication layer, where you can control the clock.
What Zerocheck covers here
Zerocheck can test the form, its validation and the confirmation the page shows. It can also test your app after login, using a test account and login steps you've configured.
It can't retrieve email. Inbox access, magic-link extraction and SMS steps aren't supported, so keep those in another harness. If your only login path goes through an inbox, sort that out during setup before you expect authenticated tests to run.