If you’re interested in automated testing for browser applications, you’ll appreciate a framework that can quickly and efficiently run your end-to-end tests. Cypress does not only that, but also provides the user with out-of-the-box tools to observe test results in action. Let’s take a deeper dive into why Cypress is the E2E testing framework of choice for many front-end developers.
Cypress is an open-source testing framework first released in 2017 and has since become instrumental to test-driven development. Success stories of development teams who have adapted Cypress abound, and in 2019, Forbes listed the testing tool a rising star within its authoritative Cloud 100 list.
While Cypress, according to their own description, can be used to test “anything that runs in a browser”, the framework is particularly well-suited for front-end developers writing their own end-to-end tests. Its easy setup, fast performance, and excellent documentation mean that anyone with some JavaScript proficiency can enjoy writing tests in Cypress.
End-to-end tests?
So what are end-to-end (e2e) tests? In software engineering, tests are a vital part of the production pipeline. They are classified according to the degree of atomicness of the feature to be tested. Unit tests ensure that an isolated piece of code (e.g., a function or a class) is doing what we expect it to do.
Next in the testing sequence come integration tests. These chain together several unit-tested features and determine whether they interact as expected. And lastly, we have E2E, where we simulate an entire workflow as a user would experience it. Example of E2E tests might be requesting a password reset or logging into an application.
Traditionally, developers have been primarily concerned with writing unit and integration tests, leaving the more complex and time-consuming E2E-tests to QA testers. However, in an agile programming environment, where requirements can change day-by-day, that approach is not longer feasible. In the agile age, it’s vital that front-end developers be able to write their own E2E tests, and as quickly as possible.
Enter Cypress testing
Developers who have made the switch to Cypress often emphasize its quick and easy setup. Whereas other frameworks ask you to download all kinds of packages, the full Cypress installation requires only three items: Node.js, npm, and a one-liner in the console:
$ npm install cypress --save-devThis command installs Cypress including all its dependencies, and creates a folder structure in your file system.
Unlike frameworks like Selenium, which allow their users to write tests in many different languages, Cypress keeps it simple: all tests are written in JavaScript. While this might at first seem like a serious limitation, it makes sense given the scope of the product. JavaScript is the language of front-end developers, and that’s exactly who the product was built for.
Keeping things simple and developer-friendly likewise pushed the Cypress team to support only the Chrome browser in their product’s early years. However, as users repeatedly requested multi-browser support. That wish was granted in February 2020, when Cypress introduced support for Firefox and Edge (see the full list of supported browsers in the Cypress docs).
Cypress comes with an interactive test runner (similar to an interactive development environment, or IDE) complete with time-travel options. This means that at each stage of a test, Cypress automatically takes screenshots of the tested web page’s behavior, which the developer can later investigate to quickly understand how the code acts in a real-world scenario.
Taking screenshots of a test’s effect on a web page is a built-in option in Cypress and happens automatically. An even handier feature for inspecting bugs is the option to record videos of a test in action. When combined with the Cypress dashboard service (a web-based inspection tool), the users can specify whether they want all test videos uploaded or just the ones that failed.
The dashboard’s true value is seen when running tests within a CI pipeline (like a pre-merge or pre-deployment validation), where it shows users much more valuable information than they could get from just viewing the output log. While Cypress offers a limited dashboard service for free, developers who plan to use this feature professionally will likely opt for the paid version.
What’s the difference between Cypress and other testing tools?
For about a decade, Selenium was the main tool for testing web applications. No wonder, then, that Cypress often gets compared to its reputable predecessor. However, not only do the two frameworks have different foci, they also use completely different architectures.
Selenium runs its test by using a web driver and accessing the browser from the outside. This modularity means that it can be used with a range of different programming languages (such as Ruby, Python, or Scala) and with any kind of browser. Cypress tests, on the other hand, run directly within the browser, alongside the front-end code itself. This makes for a big difference, catapulting Cypress to the top in terms of end-to-end test speed.
A dreaded event in software testing is the flaky test. Flakiness means that one and the same test produces both fails and passes in different runs. One of the causes for flakiness lies in the asynchronous nature of browser behavior: oftentimes, a process needs to finish before another one can succeed. This source for errors can be circumvented in Selenium by including a ‘wait’ statement. In Cypress, such cases are prevented by waiting automatically for processes to finish. This doesn’t completely eradicate the possibility of flaky tests, however. To detect and treat flakiness, Cypress has a ’test retry’ feature.
What’s clear is that Cypress isn’t here to replace Selenium totally. That’s because the frameworks’ purposes are different by design: while Selenium is more customizable and can be used for many different types of tests, Cypress was designed to do one thing (E2E testing) and do it extremely well. It’s the fixed-blade knife to Selenium’s multi-tool.
Cypress isn’t the only new kid on the block. In fact, there are many new frameworks that specialize in one or more aspects of web testing. Puppeteer is one of them, and it’s similar to Cypress in that it’s a JavaScript-based tool. However, while Cypress supports multiple browsers and acts as a standalone testing framework with its own IDE, Puppeteer is a library for the Chrome browser meant mainly for web scraping and quick testing.
Is Cypress testing for you?
Cypress testing is for anyone who wants to write and run fast and comfortable end-to-end tests in JavaScript (or, using this add-on, in TypeScript). As we’ve mentioned, it’s mainly aimed at front-end developers, for whom testing is but one step in the continuous integration pipeline. Therefore, they particularly appreciate this tool for running and debugging their tests.
But Cypress’ user base is certainly not limited to developers. If you know a bit of JavaScript, you’re likely to enjoy Cypress’ easy setup, its steep learning curve and handy visual features (such as test videos and the dashboard) that showcase your test’s behavior just like a user would experience it. In the following section, we’ll look at cases in which you shouldn’t use Cypress.
When should you not you use Cypress tests?
Sometimes, innovative architectural decisions lead to certain restrictions. This is the case with Cypress’s in-browser implementation: the specific implementation means that you can’t run Cypress in several tabs, nor in several browsers at once. In its section on trade-offs, the Cypress documentation explains this choice, and shows how tests can be run without multiple tabs. It’s also not possible to visit two URLs from different domains in the same Cypress test case.
Speaking of browsers, despite now offering support for Edge and Firefox in addition to Chrome, there’s still a glaring gap in terms of omissions from the list. This means that Apple’s Safari is not supported, which is often cited as the biggest argument against Cypress.
Finally, of course, you shouldn’t use Cypress for things it was not designed to do. Let’s say you’re a QA analyst who’s more comfortable with testing in Ruby or Python, or wish to run unit or integration tests only. You might be better suited to checking out the excellent tools built for those purposes.
Use Cypress to test email and SMS messages
Mailosaur lets QA & development teams capture, test and analyze email and SMS messages as part of their automated testing. Letting you test processes like account verification, password resets, as well as SMS access codes and more. Learn [how to test email with Cypress and Mailosaur]({{<ref "docs/frameworks-and-tools/cypress" >}}).