In our test environments, we send our emails to test inboxes on self-hosted Squirrelmail servers to avoid sending test emails to inbox service providers such as Gmail. Many important flows require the user to check their email, click on an actionable link, redirect to the web application, and then continue to a download or verification success page. We test these features manually by entering our Squirrelmail email addresses into the necessary forms, clicking some buttons, and following email links to validate that everything is working as expected. We can do this every time on new code changes to make sure we haven't regressed anywhere, but it would be nice to automate these steps into an end-to-end (E2E) test that we can run again when we want. Specifically, we'd like to write

E2E tests with Cypress, so that we don't have to manually test these potentially slow and confusing email flows in our own web browser every time. Before getting into the post, here are some articles you might be interested in reading first. If you've never written E2E tests before or want a refresher on how to think when writing E2E tests, you might want to see this blog post before you start. If you are unfamiliar with using Cypress to write E2E tests in general, we strongly recommend that you check out our thousand foot overview on implementing Cypress tests for your web applications. This will give you a better idea of ​​the Cypress API. This article assumes you are familiar with some of the Cypress functions such as cy.task()to run arbitrary code that we define in a Node server to help us process emails. Also, if the last code snippets with TypeScript are a bit confusing, it might clear things up to see our blog post on how we typed our Cypress tests.

You can always modify the code in your own Cypress tests by removing type definitions and sticking to JavaScript syntax only. We won't explain how to set up your own test inbox server (like Squirrelmail), but we will focus on automating those steps related to searching for emails, analyzing email content corresponding emails and email link tracking. This should give you a better idea of ​​what kind of functions to use and implement to handle these mail flows, assuming you have a test inbox server and your own credentials to log in. How do we manage email flows in Cypress tests? To test the completeness of mail flows, we have created plugins cy.task()for: Manage login and inbox filtering of emails with certain subject line Retrieve the body content of a matching email Deleting emails from a user's inbox without ever having to log in via the Squirrelmail UI We also went this route because we don't own or control the Squirrelmail UI, and it's not possible to visit more than one superdomain in a Cypress test since the Squirrelmail UI URLs live in one superdomain separate from our deployed front-end application. .