Tech/Engineering

Cypress vs. Selenium: What testing tool is right for you?

August 13, 2020 Rohit Shrivastva, Senior SDET

Here at Druva, we are always working to improve the quality of our solutions and the efficiency of our system testing. One of the tools that we employ to reach those goals is test automation. Selenium and Cypress both are open-source automation frameworks for web-based applications. Selenium is a long-time solution, whereas Cypress is a newborn, test automation tool.

Although Cypress is new in the market, there are a lot of questions stirring in a tester’s mind:

  • Is Cypress the replacement for Selenium?
  • Is Cypress better than Selenium?
  • Is Cypress developer-friendly or tester-friendly?
  • Is Cypress faster than Selenium?
  • Does Cypress support cross-browser?
  • Is Cypress signaling the end of an era?

Let’s dive further into the details to find the differences between these two tools and determine which is most suitable for you.

Getting started with Selenium and Cypress 

Selenium

Software Requirements for installing Selenium-

Java SDK, Eclipse IDE, Selenium Java Client driver,

WebDrivers (CromeDriver for chrome, Mozilla GeckoDriver for Firefox, etc.)

Writing your first test

This test code will open the chrome browser and navigate to http://google.com/ and search for the keyword “Selenium Rocks!”

cypress-blog-image

Cypress

Software Requirements for installing Cypress-

Node.js, Visual Studio Code

Run the following commands to starts with Cypress:

npm install cypress –save-dev

npx cypress open

Writing Your First Test

This test code will open the chrome browser and navigate to http://google.com/ and search for the keyword “Cypress Rocks!”

blog-cypress-image

Both tools can be easily installed. Cypress is simpler and there is no overhead of driver or IDE.

Language Support

Selenium

Selenium supports a wide range of programming languages using the drivers specific to each programming language. Some of the supported programming languages – Java, Python, C#, JavaScript Etc.

Cypress: It’s JavaScript Only!

Any programming language can be compiled down to JavaScript, but the test cases ultimately run inside the browser. Therefore, Cypress uses the JavaScript library only, there is no binding of drivers like in Selenium.

Wait, what?

Selenium has a large number of language supports than Cypress, does it mean Selenium is more Developer-friendly?

Selenium is a pure automation tool for testing purposes, it is not built for development purposes.

On the other hand, Cypress is built for both Developers and QA Engineers. Cypress is less of a  replacement for Selenium and more of a way to introduce developers to test automation.

Finding web elements

In Selenium, a web element can be identified by the element ID, CSS class name, name, XPath, and HTML tag name.

Cypress also has a great feature of a selector playground in the test runner for finding web elements.

cypress-blog-image1

So what is the difference?

Any UI test faces a classic problem of dreaded sleep/timeouts (flakiness).

The flakiness in the test arises because of the waiting time for the DOM to load an element or because of something (different view-port) elements moved from their location on the web page.

A typical flow in Selenium: Command → Driver → Browser

  • This flow can result in the above issue.
  • While writing a selenium test, the tester tells the WebDriver what they want, and the driver tells the browser what the tester wants. After completing the loop, Selenium clients get the response. Selenium commands are not executed in the browser, so they don’t have access to any browser information to help to respond if anything changes.

On the other hand, Cypress is not flaky. Cypress commands run in the browser, It has great control over the DOM. Cypress knows and understands everything that happens in the application synchronously. Cypress even knows how fast an element is animating and will wait for it to stop! Additionally, it automatically waits for elements to become visible, to become enabled, and to stop being covered. When pages begin to transition, Cypress will pause command execution until the subsequent page is fully loaded.

Test execution and time travel

Now, here comes one of the main differences between Selenium and Cypress.

Selenium executes all of its commands in a web driver outside of the browser in which actual testing happens.

cypress-blog-test-execution

On the other side, Cypress’s tests run inside the browser along with application code.

cypress-blog-image2

The advantage of running the Cypress process inside the browsers is that there is no network lag. It uses the same DOM events generated by the browser, so Cypress commands run as fast as the DOM is generated.

Yes, Cypress’s test execution is much much faster than Selenium.

Time travel

Time travel is yet another game-changing feature in Cypress. It takes snapshots of events while running cypress tests and can be viewed on the command panel in the test runner.

One can hover and click on each command that runs the test

cypress-blog-image3

Testing framework

Selenium does not restrict using any specific testing framework. You can write your own common code for doing any action. However, there are a number of frameworks available depending on the language you are using with Selenium. Like JUnit in Java, NUnit in C# Etc.

On the other hand, Cypress has adopted Mocha’s BDD syntax which fits perfectly with both integration and unit testing. And Chai, Chai-JQuery, Sinon, Sinon-Chai assertion libraries.

On the other hand, Cypress has adopted Mocha’s BDD syntax which fits perfectly with both integration and unit testing.

cypress-image

Cross-browser support

This is one of the biggest gaps between these two tools. Selenium offers extensive support for testing multiple browsers in parallel. On the other hand, Cypress has a limited set of browsers support.

Features Selenium  Cypress
Cross Browser support Chrome, IE, Firefox, Safari, Edge, Mobile browsers Chrome, Firefox, Electron, Edge, Brave
Multi Tab Supported Not Supported – workaround present
Multiple Browser Instances Supported Not Supported – workaround present
Installation Easy Easy
Testing types E2E, Visual, Security, Unit E2E, Visual, Unit, API
Programming Languages Java, Python, C#, JavaScript Etc. JavaScript
Testing Frameworks Junit, Nunit, Mocha, Jest, Protractor, etc. Mocha
Integrations Wide range of integrations (CI/CD, Reporting, Visual Testing ), etc. Wide range of integrations (CI/CD, Reporting, Visual Testing ), etc.
Speed Slower Fast execution
Time travel Not Supported Supported
Mock servers, Spies & Clocks Not Supported Supported
Network & Traffic Control Not Supported – workaround present Supported
Driver dependencies There is driver dependency for browsers No driver dependency
Screenshots and Videos Need to write explicit code Automatic
Mobile Testing Excellent support with Appium Not Supported
Remote Execution Supported Not Supported
Waiting time Need to write explicit code Automatic waiting
Real-time reloads Not Supported Supported
Documentations Average Documentation Excellent Documentation
Community Support Robust community Growing community

Feature comparison: Selenium and Cypress

Which one to choose?

Well, it totally depends on the requirements. Both tools have their own pros and cons.

Where Selenium fits 

If the requirement is to test on IE and needs access to external tools like SauceLabs, BrowserStack, Selenium will be preferred

Where Cypress fits

Nowadays, web application development has completely changed. If the web application is built on modern JS frameworks like React, Angular, Vue, etc., then Cypress is the best option. It will serve the common platform for tester and front-end developers to write their automation tests.

Conclusion

I hope this analysis gave you a sight of the differences between Selenium and Cypress.

Always consider a tool that fulfills the team’s requirements, scope to test, your skill-set, and think from the latest and longer-run perspective.

Happy testing!

Learn why more organizations are leaning on Kubernetes and the cloud when developing their DevOps pipeline.