If you’re undecided about which end-to-end testing framework to use for your development projects, this article will help clarify the pros and cons of each option. Based on expertise in delivering software testing and QA services and experience in using various automation approaches, our team has compared Cypress vs Playwright in terms of features, performance, and ease of use to give you a better idea of which one is right for your needs.
The Playwright is a cross-browser end-to-end testing solution. It is built on the Chrome DevTools Protocol (CDP), which enables direct in-browser automation and is supported by most modern browsers. This eliminates the need for running in a browser’s execution loop but requires an external process, like Node or other, to drive it.
Looking for more information about the Playwright automation framework and its key features? Check out our article: How to Improve E2E Testing for Web Apps with Playwright Automation.
Cypress is an Electron App that brings the power of web browsers to your desktop apps. The library and your code are directly embedded into the execution loop of the browser, meaning you can modify its default behaviour to get the desired results. Additionally, Cypress uses its implementation for this purpose; even though integration with CDP is currently in progress, it’s not exposed via its API.
The Node may also be used, but the primary control is appointed to a custom injected library. Meanwhile, Playwright delegates the control to the CDP implementation of the browser, which is standardised and supported by browser providers.
Before we deep dive into the comparison between Playwright and Cypress, let’s take a brief look at the browsers’ engines.
A browser engine is a core component of every web browser. There are five main types of browser engines powering the web browsers available today: Gecko, WebKit, Presto, Trident, and Blink. These engines are the reason for the unparalleled service from today’s most notable web browsers on the market.
From an automation perspective, it is more important that we have access to features like geolocation, permissions, service workers, and network than how a browser engine compiles JS code or renders HTML and CSS. Using DevToolsProtocols allows this access, and with its help, we can manage browser engines. As for access to the browser’s UI, we use WebDriverProtocol. If you want to take an in-depth look at browser engines, read our article: Rendering Engines and Their Role in Automated Web Application Testing.
While there are some differences between the two regarding browser support, both offer the ability to do tests and interactions in Firefox and Chromium browsers. Other similar features include taking screenshots, stub out requests, and testing on different screen sizes – all of which make these tools extremely useful.
Moreover, suppose you want to run your tests as part of a continuous integration flow or prefer to run them without a UI interface. In that case, both frameworks offer headless options that will allow you to do so directly from the Terminal.
While they both aim to solve a similar issue, they have different ways of doing so. Cypress is more of a “full package”, and it creates a folder structure along with example files, and you are stuck with the test runner you get with the framework. Playwright, however, does not make any files and can be configured to work with the test runner of your choice.
While both frameworks have different ways of running tests, Playwright’s promise-based system has the advantage of being able to support multiple browsers and users’ contexts simultaneously. This makes it more flexible and efficient than Cypress, which needs to be re-run for each different browser option.
One of the most significant benefits of Playwright is its ability to test across multiple pages and domains. Along with setting multiple user contexts. Both are very useful if you use third-party sign-ins, pop-ups, iFrames (such as BankID in Norway), etc., in your application. On the other hand, Cypress would require you to write separate tests to simulate the different user scenarios and to stub a lot of the requests to work.
|Test Runner Frameworks Support
|Mocha, Jest, Jasmine
|Headless browser with event-driven architecture
|Executes test cases directly inside the browser
|Chromium, Firefox, WebKit, Chrome, Edge
|Chrome. chromium, Edge, Electron, Firefox
|Limited (need to set chromeWebSecurity = false), and not all cases work
|Limited, there are some workerounds
|Paid dashboard or by using free plugins-workarounds
|API support from the box
|Mobile testing support
|Only view for Android
|Only view for website
Our QA team at ELEKS has been working on dozens of software development projects providing test automation services to our customers. Based on our experience, we can say that when choosing a testing framework, functionality should be the top priority. The Playwright was initially created for end-to-end testing, while Cypress is better suited for unit testing.
Cypress is the ideal solution for beginners looking for ease of installation and usage. It doesn’t provide exhaustive test evidence like network capture or video recording, but it’s perfect if you need screenshots. The well-drafted documentation and rich community support offered by Cypress are extensive, making it easy to overcome any bottlenecks or issues you may encounter.
Microsoft Corporation developed Playwright, so you can also be sure that it’s a high-quality tool with a rich support team. The Playwright is the ideal choice if you need to test WebKit and Chromium using DevToolProtocols, or if your tests need to cover scenarios spanning multiple pages and domains.
With features like screen recording, video capture and tracer viewer, Playwright has everything you need to get the most out of your testing. Plus, if you want more control over your browser or don’t need a test runner, it is the perfect solution. The Playwright framework is still relatively new, so we can expect that the community, documentation and framework will continue to improve over time.
Choosing the right testing tool for your web app is essential to streamlining the entire testing process. Make sure to select a tool based on usage and functionality to get the most out of your investment.
By Oleksandr Chako, Test Automation Engineer at ELEKS.
The breadth of knowledge and understanding that ELEKS has within its walls allows us to leverage that expertise to make superior deliverables for our customers. When you work with ELEKS, you are working with the top 1% of the aptitude and engineering excellence of the whole country.
Right from the start, we really liked ELEKS’ commitment and engagement. They came to us with their best people to try to understand our context, our business idea, and developed the first prototype with us. They were very professional and very customer oriented. I think, without ELEKS it probably would not have been possible to have such a successful product in such a short period of time.
ELEKS has been involved in the development of a number of our consumer-facing websites and mobile applications that allow our customers to easily track their shipments, get the information they need as well as stay in touch with us. We’ve appreciated the level of ELEKS’ expertise, responsiveness and attention to details.