Go with Cypress or Playwright?

Cypress and Playwright are two frameworks for UI automation that rapidly growing in popularity over the last 3-5 years. Before that, Selenium was almost keeping the monopoly in the scope of web browser automation. The core advantages over Selenium are pretty obvious: all-in-one solution, faster and more reliable test execution, less code to write, and as a nice bonus support of API testing and mocking.

But when it comes to which one to choose out of two - then debates here could have long threads of arguments between engineers :)

So, how to choose?

If you already have a personal preference and opinion on whether Cypress or Playwright you think is better - go for it. You will not make a wrong choice because both of those tools are very close. Both of them have enough capabilities to automate pretty much anything that runs in the web browser. You as an engineer will be more efficient with the tool that you like and understand. Making a switch does not really worth it unless you want to learn and try something new. In this case - you are also welcome!

If you are switching from Selenium or are new to UI test automation in general, and trying to decide which framework to choose for your project, then here is my opinion, which I hope, can help to make the decision for you!

Go with Cypress if:

• web application is small or mid-size
• application doesn't have "new tab" windows and iFrames
• need to set up something quick and running
• you are the only engineer who will work on this
• you don't expect this automation project last more than 2-3 years

Why?

Scripting in Cypress will be a little bit faster because you'll need to write less code. Cypress coding interface hides a lot of code "noise" from you such as async/await, page fixture declaration, and other stuff that is exposed in Playwright. You need fewer lines for some operations to achieve the same result.

Here is an example: clear the input field and type a new value

//Cypress
cy.get('#myInputField').clear().type('Hello World!')

//Playwright
const myInputField = page.locator('#myInputField')
await myInputField.clear()
await myInputField.fill('Hello World!')
        

Another example: several assertions

//Cypress
cy.get('#myInputField')
  .should('contain', 'Hello World!')
  .and('not.contain', 'Darkness')

//Playwight
const myInputField = page.locator('#myInputField')
await expect(myInputField).toContainText('Hello World!')
await expect(myInputField).not.toContainText('Darkness')        

We know that copy/pasting the locator is not a good thing, so had to create a constant with a reference to the locator ID. I think you got the overall idea.

Less code to write = easier to maintain. So that's why If you are the only one to make this ball rolling, it will be easier for you down the road to perform maintenance, update tests and fix the issues. If your project size is fairly small, the number of tests will also be pretty small. It means that you not necessarily will need to run tests in parallel, which in Cypress by the way is a paid feature for the Cypress Dashboard service. Yes, there are workarounds on how to do it for free, but we talk here about out of the box solution. If it is a startup, or a fast pace, rapidly changing environment - there is a big chance that this automation will not be relevant in 1-2 years. So it makes more sense to go with a fast route which is Cypress.

Want to go fast - go with Cypress

Go with Playwright if:

• web application is big or enterprise level
• it has iFrames or a "new tab" windows
• you have/will have a team of automation engineers who contribute to this automation project
• there are expectations that we build this automation to last for the years ahead
• you don't want to use JavaScript/TypeScript

Why?

Playwright will have more coding, but at the same time will give you more flexibility and room for maneuver if some unexpected edge-case scenario popped up. Imagine the case, you begin automation of some enterprise project, and then product owners decided to add a "new tab" window for a certain functionality. And well... you are stuck. Because Cypress does not support and will never support this. Or you have iFrames. Cypress can work with iFrames, but.. sometimes it does not work well for whatever reason and you need to install the plugin to enable this feature. While in Playwright - it works absolutely seamlessly! I heard the examples when teams put in the trash a year of work investing in Cypress eventually switching to Playwright because they stuck with some weird use case they could not handle with Cypress. Again, this is extremely rare! But it's possible. So if you are building something big, you carrying this risk that you can stuck with Cypress in some weird use case.

Speed of execution. Playwright is slightly faster than Cypress. Not much, but still. Also, the playwright supports free out-of-the-box parallel execution of the tests. In Cypress to run tests in parallel, you need to pay for the Dashboard Service (which is super cool by the way), or use open-source alternatives and configure it. In Playwright, just a couple of lines in the config file, and you run as many tests in parallel as you want. Even more. Cypress makes parallelization by "spec" file. It means that let's say you have two test files with 20 tests in each of them. So when you run tests in parallel, Cypress can run only two parallel threads, one per spec file. While in Playwright, you can run tests in parallel within a single spec file. So your parallelization technically is only limited by the computing power. In the big frameworks, with several hundreds of tests, the parallelization support Playwright will give a faster feedback loop, compared with Cypress.

And yes, except JavaScript/TypeScript, Playwright also supports Python, Java, and .Net. You can automate using those languages, but I would not recommend it, because only with TS/JS you'll get the maximum capabilities out of Playwright.

Want to go far - go with Playwright

Tests stability.

I saw discussions like "Cypress is more fragile" or "Playwright is more fragile". Both of those statements are false in fact. Both frameworks are super stable and have a great implementation of retries and timeout mechanisms. If your tests are fragile - the problem is in the code, not in the framework. Assuming the test application itself is stable, then the other two main reasons why you are dealing with a fragile test execution:

• Tests are not completely isolated. You have a dependency on other tests or dependency on test data. The test itself does not fully control the test data during the test run
• You don't follow the best practices for the framework or don't understand the underlying mechanism "how does it work". When you take best practices from Selenium for example and try to use the same approach in Cypress or Playwright, it does not always plays well.

Always refer to framework documentation on how to implement the solution. By the way, Cypress's documentation is fantastic! It is exceptionally well structured with a bunch of examples, code snippets, and use cases. Easy to navigate and easy to use. Unfortunately, I can't tell the same about Playwright. Don't trust ChatGPT as well. Documentation - is your best friend.

So in a nutshell what do we have?

Want to go fast - go with Cypress

Want to go far - go with Playwright

I help quality engineers advance their QA careers by getting new skills most efficiently at Bondar Academy. Boost your skills today!

URL: Bondar Academy