Selenium vs Cypress. What is the difference & what to choose?
A recent conversation with a Quality Assurance engineer at my current company prompted me to write this article. During this conversation, he asked me why I chose the Cypress? After all, all his colleagues from other companies are using Selenium and have a rather negative attitude to the first. I want to make a disclaimer that the purpose of the article is not to sell any of the tools to you but will focus on the superficial comparison. I want to shed some light on what each one is good at and how to choose the best one for yourself based on a few points. Indeed, in test automation, unfortunately, there is no ideal solution and you always have to choose “lesser evil”, and unfortunately we are not the witchers to decide not to choose at all. 😉
The first thing for the start you need to understand the project for which you are starting automation. If this is a public site with huge geography and a number of unique users, then most likely the issue of cross-browser compatibility will be key for you. Such sites often do not have complex functionality, but how they are displayed on different versions of browsers is one of the key points. Let’s see what can each of the tools offer us?
Browser support
Overall, Selenium has support for the most common browsers like Chrome, Firefox, IE, Edge, Opera, Safari. Automation of these browsers occurs by sending HTTP requests to the driver of the browser of your choice, due to which all actions will be performed natively, which means, the behavior of your application will be as close as possible to the end-user experience.
Cypress, on the other hand, as of today (fall 2021) has more limited support for the Chromium, Edge, and Firefox browsers. But the biggest drawback lies in the very principle of operation of this tool, namely, that all interactions with browsers occur through the execution of JS. Those who work with Selenium from its beginning will be able to remember its first version named SeleniumRC, which also worked through the execution of JS code on the client-side.
You may wonder “Why JS based events are bad?”.
And the problem is that JS, unlike the end-user, will be able to click on an element that has zero width and height, will be overlapped or completely hidden, and this is not to mention a number of other features. Sometimes you may face a situation then the application behaves differently under your JS-based event automation tool when if you test it manually. It can be caused by many reasons but the fact that you’ll see it less frequently in Selenium than on non-native event-based tools. In defense of Cypress, I will say that, unlike SeleniumRC, they carry out a whole bunch of checks on an element before interacting with it, unless you forcefully disable them through the {force: true} property.
So, at this point, Selenium is definitely an advantage.
Selenium: + Cypress: +-
Installation and setup
This is an important and highly underestimated point that automation engineers often overlook. Very often, automation on a project begins as a personal initiative or a trial, with unknown goals. And you must admit that few people want to spend a lot of time installing and configuring a tool that may not yet suit your project or goals. And it’s not a fact that you can convince your manager to give you a couple of weeks for this.
And in this matter, Cypress has the greatest simplicity possible — it is an installation with just one command npm i cypress. Of course, today Selenium already has a lot of frameworks that can be installed with one command and a couple of choices. But the Cypress does not even need to install a browser since it already comes out of the box. And believe my experience, even such a seemingly insignificant point more than once stopped developers from running tests locally or trying to write a couple of tests in the absence of an AQA engineer.
Selenium: +- Cypress: +
Documentation
This one is very important in the initial acquaintance with the tool and to a large extent affects the previous one — the more extensive and clear the documentation, the faster you will get the first results. Recently, the official Selenium site has made a huge step forward, but still, it is rather limited examples and there is no description of the entire API at all. Most likely this is due to multiple programming languages support, but a brief review did not bring me any result in the form of a link to a description of the available methods.
Cypress, on the other hand, has full API documentation with code examples and scenarios of their use. The site also provides videos, best practices, plugins available, etc.
Selenium: +- Cypress: +
Additional features
When we talk about automation, we often mean tests. And these tests need more than simple clicks and scrolls. Request interception, response mocking, clocks, time travel— all these are required test tools. With a few exceptions, Selenium is simply devoid of all this, since its task is to send commands to the browser, everything else is the problem of your framework and few of them can even intercept requests since technically this is not the easiest task to spy on HTTPS requests of the 3-rd party application. Cypress has it all from out of the box and it works just fine. In fact, this is one of its key features, since it was originally created as a tool for Front-End developers. So that they can write tests for their part of the code even when the Back-End part is still missing.
Selenium:- Cypress: +
Conclusions
We could talk about reports (although it will depend on the one you have chosen and for both tools there is an almost identical set), and about syntax (for example, Cypress does not use native promises, which causes a lot of inconvenience for both developers and people accustomed to using async / await) and much more, but the purpose of this article is to briefly describe the tool’s capabilities.
If we try to count all the pluses, then we can make an incorrect conclusion that some tool is better than another. But a more reasonable approach here would be to determine the points of importance of each of the features for your project and, based on this, make a choice. For example, your project is an online store with huge traffic, and you also have a couple of fairly experienced programmers (or AQA engineers) available. In this case, the issue of cross-browser compatibility will be the most important for you, and the presence of experienced developers can level the complexity of the tool — your choice will most likely be a Selenium. If, however, you are making an admin panel that will be used by about a hundred people, but at the same time, it is a single page application, with complex logic and you would like to start automation to reduce testing time — then you would rather choose Cypress.
I’m not even talking about the fact that Cypress is perfect for Front-End integration testing by developers, and Selenium can be used as a way to automate the browser, as part of your product, and not test automation. It all depends on your goals and resources. Therefore, if someone tells you that one tool is definitely worse than the other, then I suggest you just ask “In what exactly?” and only after that make a reasoned conclusion.
And that’s all for today, thank you all. And if you have anything to add, I invite you to share your opinion in the comments.
The Russian version of an article is here.
