Tricentis Testim.io

A signup or password-reset test needs to read the message and finish the user's journey. MailSlurp gives each Testim run a private inbox so concurrent tests do not collect one another's verification links or codes.

Use MailSlurp's test interface as part of the recorded browser flow. Testim's native Validate email step works with Testim's own email service; for a MailSlurp address, read the message through the MailSlurp interface or API instead. See Testim's email validation documentation for that native service's scope.

Tutorial

Setup

Start with your staging application URL, a MailSlurp API key, and the expected subject and code format or verification-link path. Keep the API key in protected runner configuration, and omit secrets from shared recordings and test reports.

Create a test-scoped inbox

1. Open the test interface and authenticate with your MailSlurp key.
2. Create an inbox for this run. Capture its emailAddress and, for API cleanup, its id.
3. Store the address in a Test-scoped Testim variable. A local variable may not survive the handoff between steps; a shared suite variable can be overwritten by concurrent tests.
4. Open your application and use that variable in its signup or reset form. Do not leave the recorded example address as a literal input.

Read the verification message

Submit the application's form, return to the same inbox, and wait for the expected email within a finite timeout. Validate its recipient and subject before reading the body. A welcome message, earlier reset or unrelated notification must not satisfy the verification step.

For suites that use a coded API helper, capture startedAt immediately before triggering the application and call waitForMatchingFirstEmail with the inbox ID, since: startedAt, a subject match and a bounded timeout. Set unreadOnly: false so inspecting the email during debugging does not affect matching. Allow the HTTP client and Testim step enough time for that wait to complete.

Store the selected OTP or link in another test-scoped variable. Keep an OTP as a string, including any leading zero. For a link, validate the expected application origin and path; emails can also include tracking, support and unsubscribe URLs.

Finish the account verification

Return to the original application tab to preserve its session. Enter the OTP or open the approved verification link, then check both the resulting account state and the user's email address. This catches a test that reaches a success page for the wrong user.

In teardown, delete only the inbox created by this run using deleteInbox, including when an assertion fails. Keep redacted inbox/message IDs and timing for failed runs; avoid storing the API key, OTP or full verification URL in shared reports.

Reliability tips

• No message before the deadline: check that the app submitted the generated address, then inspect its send event and error. Increasing a timeout cannot fix a wrong recipient.
• Wrong or stale code: check inbox isolation, recipient, subject and request start time before changing extraction logic. Fail if no unique expected code can be identified.
• Code rejected: distinguish expiry, resend invalidation and replay rejection from delivery failure. Give each negative case a fresh inbox and application user.
• SMS verification: use an assigned test phone number with its own message correlation. Creating an email inbox does not allocate a phone number; see the SMS testing guide.

Related docs

• Test interface
• Testing overview
• Wait for methods