One-time passcodes and magic links are everywhere in modern sign-in flows, and they are some of the hardest things to automate. The code your test needs arrives out of band, in an email or an SMS, on a real address you do not control. The MailSlurp plugin closes that gap: it gives a test its own throwaway inbox or virtual phone number, so the test can read the code that just arrived and complete the login for real.
This walkthrough covers the full loop: install the plugin, give it an API key, and write features that receive a message, pull out the code or link, and prove the user landed where they should. It works the same for email OTP, magic links, and SMS.
Why these flows are hard to test
A password login is self-contained: the test knows the credentials, types them, and asserts the result. An OTP or magic-link flow breaks that. The application generates a code, hands it to an email or SMS provider, and expects a human to go read it. A test that hardcodes a code will pass once and never again, and a test that skips the step entirely never proves the flow actually works.
The only honest way to cover it is to receive the real message the app sends and act on it. That needs a mailbox the test can create on demand, read programmatically, and throw away afterward, so runs never collide and never depend on a shared human inbox. That is exactly what MailSlurp provides, and what the plugin wires into your project.
Install the MailSlurp plugin
Plugins add steps you can call straight from your Gherkin. Open Plugins from the navigation rail, filter to the Integrations category or search for MailSlurp, and select Install on its card.
An install persists for the project. It stays installed across reloads and for every teammate on the project until someone removes it, so you only do this once per project. Once installed, MailSlurp's capabilities are available to every feature you write.
Give it an API key with a project secret
MailSlurp needs an API key before it can create an inbox. Never paste a key into a feature file. TestVibe keeps that value in project storage and injects it at run time.
Open the plugin's detail modal and look at the Requires section. It lists the values MailSlurp needs, each with a Set or Not set badge, and the header counts how many are still missing. You can fill the API key inline, or set it on the dedicated panel under Settings → Variables & Secrets.
Store the key as a secret, not a variable. Secrets are encrypted at rest and write-only: once you save the value it is never displayed back, and it never appears in logs, screenshots, generation context, or run output. Variables are for non-sensitive configuration like a base URL. If you ever need to point the plugin at a fixed inbox or a wait timeout, those go in as variables next to the secret.
That single secret is the whole security story. The key lives in your project, the plugin reads it inside the isolated run sandbox, and the value never travels into the application under test.
Write the OTP login end to end
With the plugin installed and the key set, you describe the flow in plain Gherkin. Keep steps at the level of user intent and let generation turn them into Playwright. Every feature starts at the site's landing entrypoint, so name the screen the login begins on rather than a URL.
Feature: Email one-time-code sign-in
Scenario: Sign in with a code emailed to a disposable inbox
Given I am on the "Login" page
When I create a new MailSlurp test inbox
And I request a sign-in code for that inbox's email address
And I read the one-time code from the latest email in that inbox
And I enter the code and submit
Then the dashboard should open
And my email address should be visible in the account menuThe important parts are the When steps that touch the inbox and the Then steps that prove success. The test creates a fresh inbox, uses its address to trigger the app's email, waits for the message to land, and extracts the numeric code. Because the inbox is created per run, two runs never fight over the same message.
Two authoring habits keep this reliable:
- Let the plugin wait for the message. Email delivery takes a few seconds. The plugin waits for the latest email to arrive rather than checking once and giving up, so a slow send does not fail the run.
- Assert something only a real login produces. End on visible evidence — an account name in the header, a page only an authenticated user reaches — not just "the code was entered." A vague
Thenlets a broken flow slip through.
Magic links instead of codes
A magic-link flow is the same shape with a different extraction. Instead of pulling a numeric code out of the email body, the test pulls the sign-in URL and visits it.
Feature: Magic-link sign-in
Scenario: Sign in by following an emailed link
Given I am on the "Login" page
When I create a new MailSlurp test inbox
And I request a magic link for that inbox's email address
And I open the sign-in link from the latest email in that inbox
Then the dashboard should openThe plugin finds the verification link in the received email so the generated test can navigate straight to it. From there the assertion is identical: confirm the app treated the visit as an authenticated session.
SMS codes work the same way
Some flows send the passcode by text. MailSlurp virtual phone numbers cover that with the same API key and the same plugin, so you do not need a second integration. Point the scenario at a MailSlurp number, trigger the SMS, and read the code out of the message body.
Feature: SMS one-time-code sign-in
Scenario: Sign in with a code texted to a virtual number
Given I am on the "Login" page
When I request a sign-in code for my MailSlurp test phone number
And I read the one-time code from the latest text message
And I enter the code and submit
Then the dashboard should openVirtual numbers are provisioned in the MailSlurp dashboard rather than created on the fly, so keep the number you are using stable across runs. Everything else — waiting for the message, extracting the code, asserting the result — mirrors the email path.
Keep it dependable
A few things make these tests boringly reliable rather than flaky:
- One inbox per run for email. Disposable inboxes mean no cross-run interference and no cleanup burden. For a fixed inbox or number, clear it at the start of the scenario so an old code cannot be read by mistake.
- Describe the code format when it's unusual. The plugin recognizes typical numeric verification codes out of the box. If your app uses letters, a different length, or a formatted string, say so in the step so the right value is extracted.
- Verify by running. TestVibe generates the Playwright for these features, but the code arriving at a real inbox is what proves the flow. Run the feature and read the trace; a green result means the message was received and the login actually completed, not that the test merely went through the motions.
Email and SMS verification stop being the gap in your coverage once a test can read its own inbox. Install MailSlurp, store the key as a project secret, and describe the flow in Gherkin the same way you would describe any other login. Get early access to try it on your own app, or read more about configuring plugins in the TestVibe docs.