DEV Community: Mailosaur

Cypress vs Selenium: Which testing framework is better?

Mailosaur — Wed, 21 May 2025 13:36:35 +0000

What are testing frameworks used for?

In general, testing frameworks are used to set up and run automated tests for web applications. It allows for elements like password reset systems, automated emails, forms for user input, and other key parts that work together to be tested, creating a reliable online application. Web apps can include a lot of categories like online stores, websites, email providers, and other tools;, and in order to make sure they work how they’re expected, they have to undergo some form of testing.

Testing frameworks come in many shapes and sizes. Some, like Selenium and Cypress, are open-source and free to use. Others require paid subscriptions and offer perks like low and no-code testing. The right option will depend a lot on what testing plans you have, and what requirements you anticipate having in the near future.

There is usually a trade-off between framework flexibility and the amount of coding required. For simple, common, straightforward testing, low and no-code options might be enough to get the job done. For more complex scenarios, creating automated tests and going with an open-source solution is the obvious choice, even if it requires some coding skill, because these options have more advanced capabilities.

Is Cypress the best testing framework?

Cypress is a popular open-source testing framework. It’s free to use, although Cypress also offers paid subscriptions for additional support and some extra features like test analytics. It runs directly in your browser so it will simulate how a real user would interact with your application. It can be used to set up end-to-end, component, and unit tests depending on your needs.

One of the advantages of working with Cypress is the documentation. They have guides on their website for getting started, installing Cypress, and tips for setting up tests. Cypress has also built a full stack example application to help people practice running tests, called the Real World App.

To help you figure out if Cypress is the right option for you, we’ll go over some information about what it’s like to use it for testing, particularly focusing on how easy it is to use, how fast tests can run, and how reliable the results are.

How easy is Cypress to use for web app testing?

Cypress is one of the most popular web app testing tools for a reason – it’s easy to setup and run tests if you have a little bit of a coding background. Installation is as simple as downloading their application or using npm. Once installed, setting up your first test can be done in minutes by following their guide for getting started. More elaborate tests can be built off the first few you create using their documentation and examples as guides.

Cypress also has a robust set of tools to help with interpreting test results, debugging, and improving test efficiency. Debugging is user-friendly, with extensive error messages and responsive code to make it easy to figure out what went wrong. They also offer the ability to take screenshots throughout the test, which can help take some of the guesswork out of debugging. If you opt for a paid subscription, you can also record the entire test using Cypress Cloud and replay it whenever you like, to pinpoint exactly when something went awry.

If you run into problems, Cypress has extensive documentation, a strong user base that helps each other out, and a support team that can answer your specific questions.

How fast and reliable is testing with Cypress?

One of the major advantages Cypress has over Selenium is speed. Cypress generally runs tests faster than Selenium, thanks to efforts put in by its developers to prioritize fast test execution.

Cypress also has tools to identify and flag flaky tests – tests where it’s possible to get a successful result or a failure without changing anything in the code. Tests like these can give false alarms for bugs that aren’t actually there and can send you on a wild goose chase trying to test and identify the error. Cypress can be set up to automatically retry failed tests, which can help identify flaky tests early on.

If you need to run the same tests regularly, you may want to focus some effort on optimizing your tests to run as quickly and efficiently as possible. With Cypress Cloud, you can run tests in parallel, automatically choose which tests are prioritized to run, and automatically cancel failed tests immediately after they fail, instead of letting them continue to use resources.

Is Selenium a better tool than Cypress?

Like Cypress, Selenium is an open-source browser-based application that can be used for testing web applications. Setup is a little more involved than Cypress, as you’ll have to choose which version of Selenium you’ll want to work with depending on your browser, your testing requirements, and the programming language you want to use.

Selenium supports a wide range of languages, including the following:

C#
Ruby
Python
Java
Javascript

How easy is Selenium to use for web app testing?

Selenium actually refers to a collection of tools, libraries, and other things that enable users to automate interactions in web browsers. This means that it has more versatility than Cypress, but with that versatility comes a more complicated setup. To help you with installation and setting up your first test, Selenium has great documentation and support sections on their website.

One difference on writing tests with Selenium is the need for wait strategies – Selenium needs to keep the code matched with the current state of the browser, so your test won’t try to interact with an element before it’s fully loaded.

How reliable and fast is testing with Selenium?

Selenium is a more hands-on approach to web-based app testing, while Cypress is specifically optimized for it, so it lacks some of Cypress’s speed and tools. That being said, for some tasks, Selenium can shine when Cypress might have a few limitations. If you needed to precisely control some aspects of the tests that Cypress normally handles automatically, Selenium has you covered.

Selenium is generally a bit slower to run tests with and requires more intensive coding skills. Flaky tests can be handled by setting up the failed tests to run multiple times to confirm they’re failures. Testing automation is only limited by the amount of time and skill you want to put into it.

For most problems you run into, Selenium’s robust user group, chat rooms, and bug tracker can help you work out a solution. If that fails, there are some companies that specialize in helping solve problems with Selenium that might be able to get you moving forward with your testing again.

How to expand Cypress and Selenium’s functionality

Whether Cypress or Selenium is a better fit will depend on your project needs and what you expect to need your testing software to do in the future. No matter what, if you find yourself limited by the software’s capabilities, both options offer support for integrations that can expand what they can do. One example of an integration would be generating and using checkable email addresses to conduct email testing in the browser, If only we could think of someone who offered that…

Learn more about web app testing frameworks

Mailosaur offers a range of software tools and integrations that can take your email and SMS testing to the next level, including integrations that work with both Cypress and Selenium to generate unlimited email addresses and come up with real, working phone numbers that you can incorporate directly into your tests. If you have questions about Cypress, Selenium, or any of our software tools, please reach out to us!

How to automate email verification with Selenium

Mailosaur — Thu, 15 May 2025 14:04:44 +0000

When people create new accounts, it’s normal for you to need a way of contacting them with onboarding information, billing alerts, and more. That’s why having the right email address is so important.

However, what if they made a typo when providing the email address? Or they simply want to create an account without any real interest in using the service as intended? In either case you’ll want to verify that they can access the email address they’ve given you.

The simplest approach adopted by most is to send a unique link in an email to that address, and have a user click on that link to verify their account. It’s simple, but it works.

But how can you test this kind of workflow with Selenium?

Why can’t Selenium test this already?

While Selenium is an extremely capable tool for testing web content and automating user journeys, it was never designed for capturing and evaluating emails on its own. At best, you could navigate to a webmail client like Gmail and try to pull content out that way, but this is time-consuming, error prone, and limits the number of email addresses you have easy access to. This has the effect of limiting and skewing results and can lead to issues going unnoticed.

So, what often happens is testers manually test their email verification process on a regular basis instead, which is significantly less robust and means it’s easy to miss a regression caused by the simplest of code changes elsewhere in the product or service.

Using Selenium for account verification testing

By adding a tool like Mailosaur to Selenium, it's possible to run the tests you need. It easily integrates with Selenium, giving you the ability to automate email tests with an unlimited number of test email addresses, so you can effectively check email verification processes, however you choose to do it.

Run tests to check any link sent to an email works as intended, which you can use for account creation, or closure processes. Whatever works for you. In the same vein, if you choose to send a verification code in your email, it’s easy to extract it for testing purposes within Selenium, or other existing test frameworks, as well.

Running these tests is simple. Here’s a quick example of such a test:

String apiKey = "API_KEY"; 
String serverId = "SERVER_ID"; // The unique ID of the inbox (server) that you are using 

// Create a MailosaurClient instance, using your API key 
MailosaurClient m = new MailosaurClient(apiKey); 

// Random test email address (this uses a catch-all pattern)
String randomString = UUID.randomUUID().toString().replaceAll("-", "").substring(7, 13);
String emailAddress = randomString + "@" + serverId + ".mailosaur.net";

// 1 - Sign up (to trigger a verification email)
browser.get("https://example.mailosaur.com/signup");
browser.findElement(By.cssSelector("input#email")).sendKeys(emailAddress);
browser.findElement(By.cssSelector("input#password")).sendKeys("my password");
browser.findElement(By.cssSelector("button[type='submit']")).click();

// 2 - Create the search criteria for the email
MessageSearchParams params = new MessageSearchParams();
params.withServer(serverId);

SearchCriteria searchCriteria = new SearchCriteria();
searchCriteria.withSentTo(emailAddress);

// 3 - Get the email from Mailosaur using the search criteria
Message msg = m.messages().get(params, searchCriteria);

assertEquals("Verify your ACME Product account", msg.subject());

// 4 - Extract the link from the email
String verificationLink = msg.html().links().get(0).href();

// 5 - Navigate to the link to verify the address
browser.get(verificationLink);
assertEquals("Your account is now verified!", browser.getTitle());

browser.quit();

Links

The crucial part here is the last part; the link or verification code inside the email itself. If it doesn’t work, your account verification process as a whole won’t work. Whether you choose a link or a verification code, Mailosaur can automatically detect and extract what you need, making it available for navigation with Selenium.

String verificationLink = msg.html().links().get(0).href();

browser.get(verificationLink);
assertEquals("Your account is now verified!", browser.getTitle());

Back in the day – How modern QA isn’t what it used to be

Mailosaur — Thu, 15 May 2025 10:11:02 +0000

Modern QA testing is hard. It’s high pressure, high tempo, and there’s a seemingly endless number of tests that need to be run.

But frankly, if you’re a young developer or QA, you don’t know how lucky you have it. Things used to be so much worse.

The more experienced professionals out there know how much better things are. They've been building programs and running tests for the last few decades, they've seen the improvement for themselves. So, with this in mind, let's take a nostalgia-tinged, dread-filled look back at those early days.

Deployment and versioning pain

These days, thanks to automatic updates, testing on the latest software versions is a relatively simple process. However, before this was a common thing, it used to be normal for any update to an OS or browser to arrive on several CDs (or, god forbid, floppy disks), then installed on a PC for manual testing.

Naturally, this was a very slow process. Updating a website or app would end up taking months, not days. And the installation process wasn’t simple either. Registries had to be manually updated, files had to be placed in exactly the right place, in the right order, and the right version had to be installed each time. It wasn’t easy.

And the installation process was just one painful element. It wasn’t alone.

DLL Hell was a common challenge developers and QAs had to face. Applications would often use a shared DLL, but weren’t always compatible with each other, so installing a new version of one application would break another, fixing that would break the other application, and so on. This meant finding version-specific bugs was nearly impossible, and configuration and deployment of apps and websites was extremely awkward.

Compounding everything, there wasn’t much support out there. While web forums existed, they weren’t highly populated, tech support wasn’t forthcoming, and documentation was patchy. If you had a problem, you were probably on your own.

Clean machine chaos

Back in the late 90s and early 2000s, unless you were working for one of the big names like Microsoft, with thousands of employees, effective testing was almost certainly out of reach. You simply didn’t have the resources for it.

Naturally, this lack of testing meant finding bugs was extremely difficult, patchy, and time consuming. That’s because it wasn’t automated in any way. It was carried out by hand, on one specific clean machine.

Because VMs didn’t really exist yet, or weren’t really viable options, you had to have a machine running the latest standard version of Windows, with no additional software for testing purposes. While this was the only viable way to test, it did make spotting software bugs and conflicts, like customers would find on their own machines, close to impossible.

VMs really were a game changer for the industry. Suddenly, you could replicate any software environment, at any time. You didn’t need to build new clean machines with the latest software every few months. It meant bugs that would only show themselves when certain scenarios arose were actually possible to find.

But VMs didn’t solve every problem.

Testing turmoil

Because of the limited capabilities of testing, it used to be very common for websites or apps, including major ones, to release updates without getting close to completing the full testing pyramid. In some cases, they barely tested at all.

This wasn’t negligence, it simply wasn’t feasible to test thoroughly like you can today. Plus, because staging environments weren’t common, any update that did roll out would involve a period of downtime. Add the two factors together, and the potential for buggy, frustrating releases was very high.

Clearly, the arrival of software deployment models was a much needed, welcome change that made thorough testing somewhat feasible. It gave QAs a sandbox to play in, testing every element of an app or website, and giving them the best chance of finding bugs before release.

Around the same time, automation tools like Selenium started to emerge, which changed the game completely. But even then, 2004 Selenium was a vastly different prospect to modern Selenium. It was harder to use, and way more limited in what you could use it for, naturally.

There was also a lot more that needed to be tested. The browser market was a lot more diverse, each with subtly different web standards. Because of this, if one browser, say Firefox, was missing features that rivals had, you’d need to use a polyfill to add it in.

So, while the mid 2000s did see the start of the modern, automated testing environment, it certainly wasn’t like it is now.

Things are pretty good, actually

Yes, modern development and testing isn’t easy. There’s a lot of pressure, and an enormous amount of complexity to modern apps and websites. Plus, a growing sense that change needs to happen immediately, not next week.

However, QA has seen so many fundamental changes over the last two decades, it’s easy to forget how far we’ve come. Modern testing tools, from old masters like Selenium to new upstarts like Playwright, have changed the landscape, while build processes, VMs, and simplified landscapes have made testing a lot quicker and simpler.

And that’s before you add in AI assistance for writing code, standardization, and more. Not to mention the bolt-on testing services you now have access to, including Mailosaur. So, while there are still plenty of things that frustrate and challenge devs and QAs every day, remember, it used to be a lot, lot worse.

If you’re a younger developer, enjoy the knowledge that you have benefitted from the (often painful) experiences of older colleagues, who had to endure some pretty stark processes to get where they are. Because we guarantee that every experienced developer will have their own horror story to tell.

So, if you’re just starting out, be sure to ask your colleagues. They’ll probably be happy to share, but they might need a beer afterwards.

How to test the functionality of fintech email notifications & attachments

Mailosaur — Tue, 13 May 2025 07:50:15 +0000

In the fintech industry, secure and accurate email notifications are essential for maintaining trust and operational efficiency across various sectors. Whether it's alerts for stock trades, crypto transactions, loan approvals, payment processing updates, or compliance reminders, timely and precise communications keep users and businesses informed, confident, and in control.

For example, account activity alerts for transactions, investment updates, or payment approvals provide transparency and build trust. Similarly, the delivery of financial statements, tax documentation, regulatory disclosures, or loan agreements ensures businesses and individuals have access to critical information when needed.

These communications are more than just a convenience—they are a vital part of safeguarding, operational transparency, and meeting regulatory compliance requirements, from payments and lending to investments and blockchain technologies.

Software teams in fintech

For software teams in fintech, testing the reliability of email notifications and document delivery systems is a critical task. This responsibility spans various areas, from banking and payments to investments, insurance, and blockchain platforms. The complexity arises from the sector's high demands for accuracy, data security, and regulatory compliance.

QA software helps teams to automate testing for email notifications and attachments, reducing errors, saving time, and enabling thorough validation of real-world scenarios. By simulating these scenarios, teams can confirm that emails and documents are delivered with precise information, and in full compliance with industry standards, including GDPR, PCI DSS, SOC 2, and fintech-specific regulations like FINRA, FCA, and GLBA, ensuring the highest levels of data protection, transparency, and operational integrity.

Why test financial email notifications & document deliveries?

Email notifications and document deliveries are fundamental to the fintech ecosystem, supporting customer interactions, operational processes, and regulatory adherence. However, testing these systems presents unique challenges:

Strict data security regulations: Emails and documents must comply with stringent standards like GDPR, PCI-DSS, or SOC 2 to ensure sensitive data is protected.
Personalized information: Notifications often include highly specific data, such as transaction details, account summaries, or policy updates, which must be accurate and private.
Complex data integrations: Notifications rely on seamless data flow from multiple systems, such as payment gateways, trading platforms, or loan management tools, to ensure consistent and accurate delivery.

Testing fintech email notification scenarios in a test environment

Simulate various scenarios in the test environment to validate that notifications are delivered exclusively to authorized users, while also confirming that the content of the notification is correct, personalized, and aligned with the specific activity or event being triggered.

Prevent unauthorized access to login workflows and 2FA:

Validate login workflows and two-factor authentication (2FA) by ensuring that email notifications, such as verification codes or login alerts, are sent exclusively to registered users.
Test scenarios where the recipient’s email address must precisely match the account credentials to prevent unauthorized access and safeguard sensitive account information.

Verify the email content:

Include transaction type (e.g., debit, credit, trade), amount, currency, and reference numbers.
Validate dynamic content fields, such as date, time, and account information, to confirm they align with the triggered activity scenario.
Test scenarios involving additional charges, taxes, or fees to ensure complete and accurate communication

Testing fintech document deliveries and attachments in a test environment

By testing document delivery/attachment scenarios in a controlled environment, Software teams can ensure that documents are securely delivered, the content is accurate, all while replicating real-world conditions to identify potential issues before deployment.

Secure Access:

Simulate the delivery of sensitive financial documents.
Attachments are accessible only to authorized recipients.
Security measures like encryption and/or password protection are implemented correctly.

Detail Accuracy:

Simulate document generation and validate the accuracy of the content.
Test specific document types to confirm accuracy.
Consistency with the recipient’s account details and activity.

Validate against edge cases, such as:

Multi-account holders requiring distinct document sets.
Automating email notification and attachment testing in the fintech industry is critical to delivering secure and accurate financial communications. By leveraging automation tools, fintech companies can ensure sensitive information such as account alerts, statements, and regulatory documents are delivered promptly and accurately, meeting industry standards like GDPR and PCI-DSS.

This not only protects customer data but also enhances operational efficiency and builds trust, making automated testing a vital practice for maintaining reliability in fintech services.

Testing Account Verification with Cypress

Mailosaur — Thu, 08 May 2025 08:17:46 +0000

Who should perform account verification testing?

Account verification is used primarily to confirm that the information defining the account is accurate and represents a real person, company, or other organization. It’s an important step for combating fraud, especially with accounts that deal with any financial transactions. It’s also a helpful tool for removing bot and spam accounts, which can otherwise waste resources and introduce security vulnerabilities.

In many account verification systems, the process is something like this: a user inputs their information into a form, the system creates an unverified account based on that form, and then the account is verified - often with an automated email or SMS sent to the email address or number the user provided on sign-up. Once the user has confirmed the email or phone is real by typing in the code, the account is changed to a verified one.

Unverified accounts often have limited permissions and functionality until they are verified. They can also be automatically checked for indications the account is fraudulent if the user does not verify the account, and even automatically deleted if they fail additional checks.

Some verification systems are more complex than checking an email or phone address. Depending on the level of security required, account verification can also involve checking if bank account details are matched to an existing account, if ID documents match photos and addresses, and more. The complexity of the system will determine the amount and depth of testing required.

As a basic rule, account verification testing should be performed by anyone using a system to verify accounts. The accuracy and functionality of the system are crucial – if the system does not correctly verify accounts, your users might not be able to access your services. Even worse, if the system incorrectly verifies fraudulent accounts, it can compromise the security of your organization.

Should you use Cypress for testing account verification?

There are several software tools out there to help you set up account testing, and Cypress is a popular option. It’s a flexible testing platform that runs directly in your browser to mimic user interactions as closely as possible, and it can be integrated easily with other tools to come up with a customized solution for your testing requirements.

A common example of this would be integrating Mailosaur’s software tools for generating real, accessible email addresses and phone numbers ready to use for testing. This is particularly helpful for account verification systems that confirm emails and phones input by users. It makes it possible to automate every step of the verification process directly in Cypress’s interface, including checking verification messages and inputting security codes.

Whether or not Cypress is the right tool for you will depend on your organization’s needs, capabilities, and resources. It may help to try a few different tools for quick and simple tests to see which are best suited.

How to test account verification systems with Cypress

Setting up a test with Cypress involves three main steps: creating your test plan, setting up and performing the test, and finally, evaluating the test results. The next few sections will go over each of these three steps in detail.

Creating a test plan for account verification

Having a thorough, detailed test plan is one of the best things you can do to set up successful and efficient software testing. While the exact contents of the test plan will depend on your specific situation, some things you may want to include are: • Detailed test outline with each step to be tested • Clearly defined goals • People responsible for testing • Where the test results and other information can be accessed

Of all of these, the test outline is often the most complex and detailed part of the plan to create. When drafting a test outline, a starting point can be listing all of the ways the user interacts with the account creation/verification process, how the software is expected to respond at each of these points, and what opportunities there are for users to input incorrect or fraudulent information.

Here is a sample list of possible user interactions and software responses for a simple account verification process that checks if an email and/or phone is functional: • User inputs their info to create an account • User inputs are checked for validity • Account verification email and/or SMS is sent based off user input • User clicks verification link and/or inputs code • Checking if account is successfully verified • User is logged into account or redirected to the right page • Confirmation email/SMS of account verification

Once you have your test plan ready to go, the next step is to familiarize yourself with Cypress and set up the test, which we’ll go over in the next section.

Using Cypress to set up an account verification test

First, if you don’t already have Cypress set up, you’ll need to install it. There are two options for this: you can either install it as a direct download or using npm. You can find additional help with installation in their documentation section. They also have a section in their documentation on setting up a simple test to familiarize yourself with their software if you haven’t used it before.

Once Cypress is ready to go, the next step is to begin writing the test using the test plan you created earlier as a reference. Tests in Cypress are structured in three steps: setting up the base state, performing an action, and checking to see if the base state has changed and how. More complex tests can involve combining multiple actions and checks in a single test, but the overall test structure remains the same.

Here’s an example of the first few steps of verifying an account: 1. Load the page 2. Input user data in the right fields 3. Submit user data 4. Check if account verification email/SMS was sent

In the example above, loading the page is how the base state is defined. Inputting user data and submitting it are two linked actions meant to change the base state. Checking to see if submitting the data triggered an automated email is how the new state is being measured. Depending on the results of the test, you can either perform more tests further along in the verification process or try to adjust your system to fix the results if something went awry.

Cypress has fairly robust error messages to help you determine why a test may have failed, and also includes color changes in the code itself to show if a step was successful or not: blue for pending, red for failures, and green for successes.

It's worth keeping in mind that sometimes when a test fails, it’s because of something in the test code itself, and not necessarily the system you are testing. Checking error messages and Cypress’s documentation can help you determine whether this is the case.

Incorporating additional software tools with Cypress

Cypress has the option to integrate other software tools to make testing easier and increase testing capabilities. A lot of account verification testing systems involve checking user email addresses and sometimes phone numbers as well, and while Cypress does not have a way to generate email addresses or phone numbers for testing, there are tools that can create both of these.

Mailosaur develops software tools and more that are specifically focused on supporting and automating end-to-end testing of systems relying on emails and SMS. Our software can be used to simulate real world interactions by incorporating working phone numbers and unlimited email addresses into your testing. This helps with testing any systems that require checking if an email address or phone number is authentic, since you will have access to any of the messages they receive.

Learn more about testing account verification

If you have questions about testing account verification, setting up automated email and SMS tests, integrating Mailosaur with Cypress, or Mailosaur’s software tools, please reach out to us!

Top Email Testing Scenarios with Cypress

Mailosaur — Wed, 07 May 2025 10:20:31 +0000

In this guide, we’ll go over the top email testing types and outline some basic steps for setting them up.

Why perform email testing?

Email testing is an important step for keeping your systems secure, testing their functionality, and maintaining a professional business. Without robust testing measures, you could end up with vulnerabilities that take a lot of effort to fix.

Making sure that emails are sent when needed and function as expected is crucial for maintaining any business. Mistakes in these communications can give your business a poor reputation with customers, which no organization wants.

No matter your reason, once you’ve decided to conduct email testing it’s important to find the right software tools to help.

Why use Cypress for email testing?

Cypress is one of the top tools for creating and running email testing for good reason. It’s flexible, adaptable, and can be tailored to run email tests for account verification, password resets, automated emails, marketing campaigns, and more. It’s also easy to build new tests starting from old ones, so expanding can be less resource-intense than you might expect.

One of the best things about testing with Cypress is how it mimics real user interactions. It’s a browser-based testing platform, not an internal test, so when it runs a test it can interact with your system like a real user might. This helps provide accurate test data that matches how your system performs in the real world.

While Cypress has a lot of built-in functionality, there are some instances where you might need it to do more than it can out of the box. Fortunately, Cypress can easily be customized to run specialized tests that can help pinpoint problems with emails before your users find them the hard way.

Common email testing scenarios with Cypress

Setting up tests in Cypress is fairly straightforward. You’ll need to download and install Cypress and familiarize yourself with the documentation on their website, which includes some examples to work through to get adjusted to their software. Setting up a test involves identifying the base state, what you plan to change, and what you are measuring after to see if the base state changed.

While Cypress can be set up to run many kinds of email tests, it’s easier to get started with some of the more common scenarios. We’ll go over the specifics for the most common email tests in the next few sections:

Testing account verification emails
Testing password reset systems
Testing order and shipping notifications
Testing email newsletters
Testing surveys, links, and other interactive emails
Testing account verification emails with Cypress

Many account verification systems use automated emails for checking accounts. Verifying an email address is a relatively simple step to take to secure accounts. It’s usually implemented into the account creation process so that when a user inputs information, the account is created with limited permissions, and an email is sent to the user’s email address. Once the user proves they have access to that email address, their account is verified and permissions updated.

Outlining the process above can be used to set up the steps for a test in Cypress. Here is a list of steps to test based off the general overview of a simple account verification system:

User clicks a link to create an account
The website page for new account creation loads
User inputs information into each of the fields
User clicks a button to submit the data
The account is created with permissions for unverified accounts
An automated email is sent to the user’s email address
The user clicks on the link in the email
The account status is changed to verified

The steps needed to test your system may vary from these, and it should also be noted that this is only one scenario where the account created was made by a legitimate user. In order to test the system properly, it’s important to test what might happen if things did not go according to plan. What is the system supposed to do if a bot tries to create an account, if the information inputted into the form is incorrect, if the automated email times out before the user clicks the link, or other situations?

Testing password reset emails with Cypress

Like account verification emails, password reset emails are another part of keeping accounts secure. When a user forgets their password, as is bound to happen sometimes, the password can be reset by an automated system that allows the user to create a new password. Many times, this system relies on sending an email with a link that permits the user to reset the password. This helps keep accounts from being reset by people who are not tied to them, which can affect your system’s security.

When setting up password reset email tests, it’s important to consider what other steps the user may have to take to prove they are the owner of the account. Some systems may require the user to complete a captcha to prove they are not a bot. Other systems may require the user to confirm the answer to a security question or some other personal data associated with the account. Whatever means your system uses, you’ll probably want to make sure your test includes all of them.

Here is an example outline of the testing steps you might need when setting up a test in Cypress:

User clicks a link to reset their password
User completes a captcha
User inputs an answer to a security question
The security question is checked against a stored answer
A password reset email is sent to the user
The user clicks a link in the email
The password reset page loads
The user inputs a new password
The password is checked against password requirements
The new password is stored
A confirmation email is sent to the user

Tips for testing other types of emails with Cypress

The process for setting up email tests in Cypress follows the same format as above – create an outline of the process and identify the steps a user might experience, then write the test in Cypress. Here are a few others you might need.

Order and shipping confirmation emails for online stores If you have an online store, you probably have some form of automated order confirmation emails and shipping emails. To set up tests for these kinds of emails, you may have to work with your payment processor to enter a test mode, which can be used to create fake orders without charging any real accounts. Alternatively, you could set up a fake product and set up test orders for it, check that the emails have sent properly, and then delete the fake orders and product.

Email newsletters, surveys, and interactive emails For some emails, you might choose to include additional elements like customized content based on the recipient, interactive inputs like surveys, and other interactive content like games, customized product lists, and more. When setting up Cypress tests for these types of emails, you may want to pay attention to what browsers and email providers are most commonly used by your recipients and run your tests to simulate emails under those conditions. This is important because how emails show up depends a lot on the provider and the user’s software and hardware.

Learn more about email testing

When setting up email tests, you might find it helpful to add some additional functionality to Cypress through integrations like those offered by Mailosaur. Mailosaur specializes in email and SMS testing, and provides an integration for Cypress that allows you to generate and check real email addresses directly within the testing environment, which means your tests can become more automated and efficient. If you have questions about email testing, Cypress, or integrating software with Cypress, please reach out to us