cypress UI

Both Cypress and Selenium WebDriver are test automation frameworks that support end-to-end testing, and when Cypress is mentioned, there is an immediate need to compare or determine which is superior.

Understanding why Cypress and Selenium WebDriver are architecturally different will help you understand the differences and similarities between the Selenium WebDriver and Cypress frameworks.

The following are the key topics that we will cover in this article,

Why choose Cypress?

Comparing Cypress and Selenium WebDriver

By the end of this article, you will be able to understand the ways in which Cypress is different and similar to Selenium WebDriver and how it shows prowess in frontend web automation testing.

Why choose Cypress?

Cypress is an end-to-end testing framework that is written by developers, for developers and Quality Assurance (QA) engineers. Cypress focuses on testing web applications and since the only way to automate the web is by using JavaScript, Cypress only supports the use of JavaScript to write its tests.

Cypress was specifically written for frontend teams that utilize JavaScript for the
development of their products, along with teams that need to quickly get started with the process of writing unit, integration, and end-to-end tests without the complicated intricacies of properly setting up a testing framework.

Cypress is not only beginner-friendly, but also ensures that everything that a developer or a QA engineer needs to get started on their tests is already packaged in the bundle that is downloaded and installed from the Cypress website. Cypress comes bundled with its own browser, a test runner, and chai as an assertion framework.

Having a bundle that contains everything required to get started with the process of writing tests means that anyone can just get started on the business of testing without needing to know about the setup process for assertion frameworks, test runners, or even the addition of browser drivers, such as in the case of using Selenium WebDriver.

Cypress makes use of JavaScript, which makes it significantly easier for JavaScript developers to onboard and quickly grasp the Cypress concepts. The ease of onboarding also ensures that developers and QA engineers can quickly get up to speed with writing tests using Cypress.

Since Cypress is developed in JavaScript, developers and QA teams using JavaScript find it easier to debug and also understand the errors as they are similar to those in JavaScript applications

Cypress makes use of a universal driver that is currently compatible with Firefox, Edge, Chrome, and the Chromium browser family. In comparison to Selenium, which uses WebDriver to interact with the Document Object Model (DOM) via HTTP network requests, the Cypress driver works directly in the browser without the need for network requests. The ability to run the tests inside the browser ensures that Cypress can effectively understand commands without introducing timeouts when commands are passed from the tests to the driver and then to the browser-based application.

Using a universal driver also ensures that Cypress maintains the consistency of the methods used in all browsers, as well as a standard format for the tests regardless of the browser in which the tests are run. With this approach, a QA team or an individual developer can expand their cross-browser testing by simply running their existing test suites against the newly supported browser with Cypress.

Also, check Permanent WFH Software Testing Jobs

Because it is architecturally unique from other test automation tools such as Selenium WebDriver, the Cypress framework runs in the browser. Cypress’s ability to run in the browser gives it a competitive advantage over other automation tools because it includes automatic wait sequences that would otherwise need to be defined in tests. Cypress thus knows when to wait for an event, such as a network request, that would otherwise require an explicit or implicit wait in a Selenium-driven test.

Software development technologies, such as JavaScript frameworks, evolve faster than testing technologies and frameworks. Cypress provides a unique opportunity for developers and QA engineers to quickly get started with the process of writing tests without having to worry about testing setup. Removing the concern about the underlying test infrastructure not only speeds up the testing process, but also ensures that teams can get started on the tasks that matter and are critical in the software development life cycle.

Selenium WebDriver vs Cypress: What’s the Difference?

Comparing Cypress and Selenium WebDriver

It’s easy to believe that Cypress is a replacement for Selenium WebDriver and that its use will make Selenium WebDriver completely redundant in the world of testing automation.

We will describe why Cypress is unique and how its purpose is more complementary than supplementary to Selenium WebDriver.

Browser driver

Cypress utilizes a custom universal driver for all the browsers that it supports, while on the other hand, Selenium WebDriver utilizes different drivers for each of the different browsers that it supports. The ability to use a universal driver for all the browsers means that on installation, we can run our tests on all the Cypress-supported browsers without the need to install an external driver. Selenium, on the other hand, requires a driver for every browser to be able to run tests in different browsers. The universal driver also gives Cypress a competitive edge as the team developing it is able to fix problems that are common in WebDriver, and can extend the functionality to different browsers.

Retries and waits

Cypress comes with built-in explicit retries to search for elements in the DOM and
explicitly waits for events to happen before a test is considered to have failed. Cypress comes coupled with events that determine whether requests need to be waited for before the browser decides whether they have failed or passed. Cypress is able to handle the waits and retries because it runs on the browser with the tests and is able to understand the state of the tests at any given time.

Also, check Understand 7 Software Testing Principles Before You Regret

Selenium, on the other hand, utilizes HTTP requests to WebDriver and it is therefore difficult for the framework to determine whether explicit or implicit waits are required when the tests are running. To solve the problem, Selenium users have to write the waits themselves in situations where the tests would need to wait for a request to complete before proceeding to the next step of execution. Selenium also does not come bundled with automatic retries when the tests are run, a feature that Cypress does possess.

Target usage

Cypress is built for JavaScript developers and QA engineers who want to quickly set up an automation framework and get to testing their end-to-end web applications, without spending too much bandwidth on setting up test frameworks or understanding the technologies behind building test frameworks. With Cypress, it is easy for developers to go beyond writing unit tests, to writing integration tests and even acceptance tests with features such as stubbing external dependencies, and testing how their applications behave. Cypress also currently favors developers and QA practices that are consistent with the Chromium family of browsers including Edge, with the addition of Firefox, which is
currently in beta testing.

On the other hand, Selenium WebDriver is built to test anything that runs on the web. Selenium focuses on QA teams that want to test every aspect of their web applications and is not limited by factors such as browser compatibility or a single test runner, which is the case in Cypress. Selenium WebDriver gives the user options to extend it with different browsers and plugins, and also supports different languages such as Java, Python, Ruby, C#, JavaScript, Perl, and PHP.

Also, check Top 15 API Testing Interview Questions and Answers for Freshers and Experienced

It is really difficult to plainly say that Selenium is a direct competitor to Cypress, as we can vividly see that while their use cases are closely similar, their audience and target users are totally different. While Selenium targets users of all major development languages, supporting even mobile automation in tools such as
Appium, Cypress is only focused on making testing better for JavaScript web developers and QA engineers that understand the JavaScript language.

Architecture

Cypress runs on the browser and this gives it an edge over tools such as Selenium WebDriver. Running on the browser means that Cypress is significantly faster and can interpret commands quicker at runtime, as there are no third-party services interpreting the commands on its behalf or sending HTTP requests to the browser driver. While all the Cypress commands run inside the browser, it is possible for Cypress to tell what is happening outside the browser, as it has access to everything that the application has, including the window object, the DOM, a document object, or any other process and method.

As long as your application has access, then Cypress tests will have access. The following diagram shows the architecture of Cypress versus the Selenium WebDriver architecture. Where in Cypress, the execution takes place in the browser, in Selenium, the execution takes place outside the browser:

Cross-browser compatibility

Cypress does not currently support all major browsers in the way Selenium WebDriver does. Cypress is currently supporting browsers built using the Chromium open source project, Firefox, Edge, and Electron (the default browser in Cypress). On the other hand, Selenium has support for all major browsers and this gives it an advantage when it comes to the ability to test applications on multiple platforms. While it is possible to argue that cross-browser functionality across more than three browsers increases the architecture complexity with minimal value to the testing process, support for multiple browsers may
lead to identifying bugs that are of high priority, even though the severity of the bugs could potentially be low

Cypress trade-offs

As mentioned previously, Cypress is a test automation tool that is focused on end-to-end test automation on the browser. Being able to run on the browser means that Cypress can interact with the elements on the browser better than any other tools but it also means that Cypress has permanent trade-offs that cannot be changed due to its architecture. The trade-offs are described in the following subsections.

Scope limitations

Cypress works best when used as an automation utility for QA engineers and developerswho are writing tests. Cypress does not support tools for manual automation and has no plans to integrate manual testing tools in the framework.

Also, check Most Important Java Interview Questions and Answers

Cypress is also not designed for activities such as web indexing and performance testing, and carrying out such activities may reduce the performance ability of the framework.

Environment limitations

Cypress runs on the browser and that means the language it supports will always be JavaScript, as the test code will always be evaluated in the browser. Being able to run in the browser means that to connect to a database or a server we can only use the Cypress commands of cy.exec(), cy.request(), or cy.task(), which provide a way to expose the database or the server, which might be more work than if we could explicitly define their configurations and Cypress understood them. Having tests run in the browser creates a great experience for running tests, but it is a little cumbersome to plug in functionality that needs to run outside the browser.

Multiple browsers and multiple tabs – limitations

The Cypress framework does not support the ability for a test to control multiple browsers when running. This is a permanent trade-off since the ability to control multiple browsers is not possible when running tests within one browser.
The Cypress framework does not support the ability to interact with more than one browser tab, as this functionality is not exposed inside the browser. However, Cypress provides the ability to incorporate other tools such as Selenium or Puppeteer to operate and drive multiple browser tabs when needed

Also, check QA Experienced Jobs

Control origin limitations

Cypress only supports visiting URLs that are from the same origin in the same test. The control origin limitation means that for any particular test, you are not able to visit different URLs that do not belong to the same origin. An example would be trying to send a request to https://github.com and https://gitlab.com in the same test, which would lead to an error. The following examples illustrate the improper and proper ways of utilizing the cross-origin when writing Cypress tests.

The proper way of utilizing cross-origin to run tests

In the following test, the user prompts Cypress to first navigate to the https://
github.com GitHub website and then to https://docs.github.com/en
(documentation link) for the GitHub resources. Both of the links belong to the same origin, github.com, and therefore Cypress would have no issue executing the requests.

The improper way of utilizing cross-origin to run tests

In this test, the user prompts Cypress to first navigate to https://github.com, then
later navigate to https://gitlab.com, which is of a different origin to the first URL.
This will lead to an error being thrown when the test is run:

Cypress and Selenium complementary actions

We can utilize both Cypress and Selenium together in some instances that are rare but still achievable when writing our tests. While Cypress has the limitation of not being able to control more than one browser tab, it is possible to configure Cypress to use Selenium to run multiple tabs. We can also utilize Cypress for our end-to-end tests and Selenium for activities such as load tests. Selenium has the ability to perform tests such as load tests, which are not supported in Cypress, and in such instances both test frameworks can be utilized together.

Frequently Asked Questions