Getting started with Cypress.io… to ditch Selenium once and for all

When you think of UI testing, Selenium is probably the first what comes to your mind. No wonder. It’s the most widely used E2E test platform. Selenium Web driver is used either directly or through other frameworks like Angular’s Protractor. Did you ever use it? If yes, then you know that it has several problems. In fact, using it can be a real pain in the arse.
Cypress.io seems to be a solid competitor for Selenium. The platform is built from scratch, uses an entirely different approach and allows developers to avoid a lot of problems that it’s older colleague had. What problems? Let’s identify them before we put our hands on coding first tests with Cypress.io.

What is Selenium suffering from?

Selenium is a project started a decade ago. The web was very different back then. Applications were stateless and straightforward, each user interaction caused full page refresh, there weren’t many asynchronous operations. Right now it evolved. JavaScript became a lot more than a simple scripting language used for form validation or fancy animations. Front-end applications are complex systems full of async operations.
Writing automated E2E tests of modern web applications with Selenium isn’t a pleasure. Because of its poor support for asynchronous operations, the synchronisation of tests and the tested app is not easy to achieve. In a lot of cases, the results are not consistent between each test run. The test should be reliable, but in this case, it’s tough to write them this way. Cypress.io makes it super easy. It synchronises with the tested page rather naturally, therefore prove itself to be very intuitive. Our tests show that it just works as expected!
Another problem of Selenium is that all the feedback we get from it are just lines listed on the console, which is not only uninformative but also very enigmatic when it comes to error descriptions. It takes a lot of time to debug the tests and find what the problem is. Cypress.io brings it to another level. The rich interface shows precisely what is going on with our tests making it easy to debug.

Installing Cypress.io

To get started with Cypress, we need to install it to our project. We need to have Node.js installed in our system. Then run the following commands while being in the project directory.

This will create test files structure and sample test file along with opening cypress test runner window.

Writing our first test

The tests are pretty simple to write. Similar to Selenium, Cypress.io gives us a few methods allowing us to simulate user behaviour on the page. They seem to be better organised and more comfortable to understand than those available in Selenium. Our first test may look like this:

Then we can write more sophisticated tests, but with excellent documentation that Cypress provides, it is easy to do so. We can also group our tests to make them more organised.

Cypress amazing features

As I’ve mentioned, Cypress.io interface helps a lot with debugging our tests. An interactive timeline shows all the events happening in our app. It lists not only interactions and assertions we are making with our test code, but also other crucial events like page redirects and HTTP requests. We can hover each of those events to lookup the state of the application from the moment it was triggered. We can see precisely what happened at the given moment.
Debugging with Cypress.io is a piece of cake. Also, all the error messages are beneficial, they don’t just state what is the problem, but also suggest what can be done to fix them. In the example, when you try to click on multiple elements at once, it will not only tell you that this behaviour is not available by default. It will also suggest what additional parameter to use to make it happen.
Another cool thing is that Cypress is trying to act like a real user and it’s equipped with some pretty smart mechanisms. The best of them is that Cypress checks whether each of the items we try to click is visible to the user. Let’s imagine a scenario when because of our code modification, a button is covered by another element. It cannot be seen nor clicked by the user. Selenium does not care whether it’s visible or not. Still, Cypress will examine it’s visibility first and result with failed test (of course suggesting how this mechanism can be bypassed when intended).
Responsive web design is another standard that was not a thing ten years ago. If you want to test your app against different screen resolutions, Cypress makes it easy. You can set the viewport size for each of your tests and even use predefined values for iphones, ipads and mac devices.
Cypress architecture benefit is that tests are run side by side with the application code. This way we can have access to our application code directly from the test script. It gives us a few excellent features. One is that we can stub or spy on our application methods. Another, which is even more useful is an ability to intercept HTTP requests, and instead of hitting our production servers, we can proxy the requests or return predefined responses. It might be helpful in case we’d like to test how our application behaves when our backend API return server errors.
Last but not least of the goodies we get with Cypress I’d like to mention here is the headless mode. Instead of calling open command, we can start run command which runs Cypress in headless Chrome additionally recording the whole process to mp4 file. Very useful in Continuous Integration scenarios and available out of the box.

What can we miss?

Of course, Cypress is not all that sugar sweet. We can miss a few features that Selenium has.
We might miss some of the Selenium’s additional tools. In the example, we cannot record the tests just by clicking the website. This feature available in Selenium might be useful when QA Engineer without programming background wants to create a set of test cases. Cypress tests have to be written directly using JS code.
Another problem might be a lack of support for browsers other than Chrome. Cypress author, Brian Mann claims that it is just a matter of writing another driver for it, that its architecture allows Cypress to be used with other browsers. Still, so far there is no option to test it with Internet Explorer or Firefox, so cross-browser compatibility is not something we can test yet.

Should we go with it?

As our apps are growing bigger and bigger, regression becomes an essential factor in its maintenance. Breaking some well-working functionalities while creating new code is something that both developers and customers hate. Automated tests are a solution to that problem.
So far, it was hard and unpleasant to write and maintain them. Until now developers were sentenced to use Selenium which slowly becomes deprecated and can’t keep up with modern web applications standards. There is nothing more frustrating than spending more time on writing test case than the feature itself. Cypress showed that E2E tests should be easy to write and encourage developers to use it.
Most of the apps we write at Gorrion use sophisticated, modern web stacks based on React and Angular. Experienced with the problems related to Selenium, we decided to switch our tactics and use Cypress as our primary E2E tool. It works as expected and makes our lives a lot easier. We definitely recommend it.