Cypress or Playwright? Which one to choose?

Let's take a deeper dive into the subject to determine which of the two frameworks is a better fit for your project or organization. Let's go!

Cypress and Playwright are two frameworks for UI automation that rapidly grown in popularity over the last 3-5 years. Before that, Selenium had almost maintained a monopoly in web browser automation. The core advantages over Selenium are pretty obvious: an all-in-one solution, faster, more reliable test execution, less code to write, and, as a nice bonus, support for 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 :) 

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 tools are very similar. Both of them have enough capabilities to automate pretty much anything that runs in the web browser. As an engineer, you will be more efficient with the tool you like and understand. Making a switch is 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 are trying to decide which framework to choose for your project, here is my opinion, which I hope can help you make the decision!

Go with Cypress if:

• A web application is small or mid-sized

• Application doesn't have "new tab" windows and iFrames

• You need to set up something quickly and run

• 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's API hides a lot of code "noise" from you, such as async/await, page fixture declarations, and other features exposed by Playwright. You can achieve the same result with fewer lines for some operations.

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

//Cypresscy.get('#myInputField').clear().type('Hello World!')//Playwrightconst myInputField = page.locator('#myInputField')await myInputField.clear()await myInputField.fill('Hello World!') 

Another example: several assertions

//Cypresscy.get('#myInputField')  .should('contain', 'Hello World!')  .and('not.contain', 'Darkness')//Playwightconst myInputField = page.locator('#myInputField')await expect(myInputField).toContainText('Hello World!')await expect(myInputField).not.toContainText('Darkness')

Less code to write = easier to maintain. So that's why if you are the only one to get 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 you do not necessarily need to run tests in parallel, which, by the way, is a paid feature in the Cypress Cloud service. Yes, there are workarounds to do it for free, but we're talking here about an out-of-the-box solution. If it is a startup or a fast-paced, rapidly changing environment, there is a good chance this automation will become irrelevant in 1-2 years. So it makes more sense to go with a fast route, which is Cypress.

Go with Playwright if:

• A web application is big or enterprise-level

• It has iFrames or a "new tab" window

• 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 require more coding, but it will also give you more flexibility and room to maneuver if an unexpected edge case pops up. Imagine the case: you begin automating an enterprise project, and then the product owners decide to add a "new tab" window for a specific 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 of teams putting a year of work into Cypress, then switching to Playwright because they couldn't handle a weird use case with Cypress. Again, this is extremely rare! But it's possible. So if you are building something big, you are taking on the risk that you could be 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 them yourself. 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 supports parallelization via "spec" files. 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 is technically limited only by the computing power. In large frameworks with several hundred tests, Playwright's parallelization support will give a faster feedback loop than Cypress.

And yes, except JavaScript/TypeScript, Playwright also supports Python, Java, and .Net. You can automate with those languages, but I wouldn't recommend it, because only with TS/JS will you get Playwright's full capabilities.

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 great implementations of retry 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 a 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 apply them in Cypress or Playwright, it doesn't always work.

Always refer to the framework documentation for guidance on implementing 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?

Microsoft Playwright is growing in popularity on the market very quickly and soon will be a mainstream framework and replace Selenium over time.
Get the new skills at Bondar Academy with the Playwright UI Testing Mastery program. Start from scratch and become an expert to increase your value on the market!