The sign up flow may be the most important one in any product. It’s usually quite simple, but with continuous integration and deployment it can also break at any time when pushing new code. And a user that cannot sign up, it’s a user that most probably won’t come back.
Specially as a solo developer, I try to automate testing as much as possible, in particular to avoid breaking things while adding new features. I’ve talked about Cypress in the past. It’s a really easy to use end-to-end testing framework for developers, that in addition to run in your desktop you can add to your CI/CD pipeline and run tests after deploying to your integration/staging/dev environment.
The sign up flow that I wanted to test, and the most common one, requires users to write their email address, then an email is sent with a link to validate that address and continue with the sign up flow. How can we easily get a new email address and retrieve the validation email in every test run?
Use a regular inbox
You could use a regular GMail address using the “+” trick to create unique addresses, and then connect to it using some POP/IMAP library to retrieve the email. But from a code perspective, it’s a little too complicated.
Use a test mail service
The second option is to use some service that provides this feature. I first tried to sign up to Mailtrap, but they sign up flow didn’t work. So I kept looking and found testmail.app (a practical example of what happens when the sign up flow doesn’t work, the user finds another product). They have a free plan that’s enough for small projects, where you can create email addresses and retrieve the email contents with a simple Rest API call.
From the Cypress side, you need to use their “tasks” feature to run the asynchronous code that fetches the email, and some regular expressions to extract the link and visit it.
Practical example
I’m gonna leave here an extract of how I used this service and Cypress together to write a test for my sign up flow:
I really recommend to write some end-to-end testing in this way, to make sure that at least the critical paths in your product work after every new deploy.
