Getting started with… 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 most widely used E2E test platform. Selenium Web driver is used either directly or through other frameworks like Angular’s Protractor. Did you ever used it? If yes, then you know that it has several problems. In

When you think of UI testing, Selenium is probably the first what comes to your mind. No wonder. It’s most widely used E2E test platform. Selenium Web driver is used either directly or through other frameworks like Angular’s Protractor. Did you ever used it? If yes, then you know that it has several problems. In fact using it can be a real pain in the arse. seems to be a solid competitor for Selenium. The platform is built from scratch, uses completely 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

What is Selenium suffering from?

Selenium is a project started a decade ago. The web was very different back then. Applications were simple and stateless, 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 it’s poor support for asynchronous operations, the synchronization of tests and tested app is not easy to achieve and in a lot of cases the results are not consistent between each test run. Test should be reliable, but in this case it’s really hard to  write them this way. makes it super easy. It synchronizes 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 is the problem. brings it to another level. Rich interface shows exactly what is going on with our tests making it easy to debug.


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 following commands while being in 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, gives us few methods allowing us to simulate user behavior on the page. They seem to be better organized and easier to understand than those available in Selenium. Our first test may look like this:

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

Cypress amazing features

As I’ve mentioned, interface helps a lot with debugging our tests. 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 is a piece of cake. In addition all the error messages are very helpful, they don’t just state what is the problem, but also suggest what can be done to fix them. In example, when you try to click on multiple elements at once, it will not only tell you that this behavior 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 weather each of the items we try to click is visible to the user. Let’s imagine scenario when because of our code modification abutton is covered by another element. It cannot be seen nor clicked by the user. Selenium does not care weather it’s visible or not, but 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 test script. It gives us few nice 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 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 few features that Selenium has.
We might miss some of the Selenium’s additional tools. In 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 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 it’s architecture allows Cypress to be used with other browsers, but 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 important factor of it’s maintenance. Breaking some well-working functionalities while creating new code is something that both developers and customers hate. Automated tests are solution for 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 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.