The test inbox

Plenty of important journeys route through email. Sign up and you get a confirmation link. Reset a password and you get a token. Log in and you get a one-time code. Testsnag gives every workspace a real inbox so those journeys can be tested end to end rather than abandoned at the point the email is sent.

1234

1. 1The generated inbox address. Reference it from a step as a double-braced token.
2. 2Copy it if you need to paste it somewhere by hand.
3. 3Filter by test once several tests are receiving mail.
4. 4Messages your tests receive appear here, which is the first place to look when a wait-for-email step times out.

The address token

Reference the inbox in any step with the email address token and Testsnag substitutes the real address at run time. Type it into a sign-up form and the resulting mail lands somewhere the test can read it.

Type {{email_address}} into the email field

Per-run and stable addresses

A test can use a fresh address for every run or a stable one that stays the same. Per-run addresses are the right default for sign-up flows, because most products refuse to register the same address twice, and a fresh alias sidesteps that entirely. A stable address suits a flow where the account already exists and you are only checking that mail still arrives.

Waiting for mail and reading it

A wait-for-email step pauses the run until a matching message arrives, matching on subject, sender, or body content so a newsletter does not satisfy a step waiting for a password reset. Once it arrives, later steps can reference values pulled out of it, most usefully the first link or a one-time code, which is what makes "click the confirmation link" expressible as a step.

Sending mail from a test

Tests can also send an email, which is how you exercise the other direction: a support inbox that should auto-reply, or a parser that should turn an inbound message into a ticket. The Email page in the sidebar shows what has arrived, which is the first place to look when a wait-for-email step times out.