Years ago, I publicly stated that “Cypress is not suitable for real web test automation” (in posts on LinkedIn and my blogs before 2021), during a time when Cypress was super-hot. I received a few cyber-personal-attacks by Cypress-lovers (not after 2024, as it turned out I was right after all).
There are many “Dump cypress and migrate to Playwright (or back to Selenium)” articles. Today, I came across one titled “Why we switched from Cypress to Playwright” by S Varun (September 18, 2024). This piece stood out as being more objective and, more importantly, with specifics and real-world examples (even scripts).
I’m sharing a few key highlights here, along with brief annotations.
Time Frame
In “Mid-2020”, “We chose Cypress owing to its popularity and simplicity.”
“switched from Cypress to Playwright in late 2023.”
That’s 3.5 years wasted (for a testing team). Judging by the challenges they faced, their testing likely provided little value to the development team, as they were constantly grappling with Cypress-related issues. After battling with Cypress for over 3 years, Cypress is effectively "dead" to them, much of their accumulated “Cypress knowledge” has become nearly worthless.
Now, imagine you’re the owner of the company—how much did that bad decision cost?
“Many Issues with Cypress”
“While things were smooth sailing initially, we soon encountered many issues with Cypress”
Here, I want to point out one important aspect: we are talking about the issues with a test automation framework itself, not testing your app. One long-lasting issue with automation framework is already too many, let alone many.
I'm not claiming that Selenium WebDriver has always been entirely issue-free. Over 14 years, I've encountered two problems with new versions, both of which were resolved within 12 hours. That level of support is the best anyone can expect in the software industry—and it’s free!
To give you a more practical perspective on real E2E test automation in Agile/DevOps, my WhenWise test suite consists of over 500 raw Selenium WebDriver tests and conducts regression testing daily. A successful run means that each of the 30,000+ Selenium steps passes.
Maintaining a large E2E automated test suite is highly challenging (the app is consistently changing). With my approach, best practices and tools, I could handle a suite of ~1000 user-story E2E tests. However, the framework has to be super reliable. Can I tolerate even a single issue with the automation framework itself? Absolutely not— one framework issue would drive me crazy. Cypress has many! see the below, from the article.
“Cypress Cloud: Very Expensive”
Cypress marketing teams have consistently emphasized Cypress as an open-source tool.
Some people believed that, thinking they could use alternative Cypress-compliant services if necessary. Well, that’s naive.
“Cypress Cloud is a very expensive platform. A few third-party providers like Currents.dev and Testomat provided similar services at much more affordable costs. However, Cypress version 13 blocked all third-party reporters.”
Cypress could easily change that while still maintaining its "open-source" claim on its website. Will any customers file a lawsuit against Cypress.io for locking them in with a false claim and then charging high fees? I doubt it.
“While Cypress supports parallelism and orchestration, it is blocked behind a paywall with a subscription to Cypress Cloud.”
I anticipated this. As a startup backed by VC funding, Cypress.io naturally prioritized revenue under pressure, making it unsurprising that it would compromise its values.
In contrast, Playwright is backed by Microsoft, where money isn’t a constraint. For true openness, however, I prefer Selenium WebDriver, which is based on the W3C standard—can’t beat that.
Cypress: Poor Performance
“Cypress is the slowest of the e2e testing frameworks available in JS.”
This article even showed a simple benchmark example (with script):
“The results speak for themselves. While Cypress took 16.09 seconds to finish the execution, Playwright took only 1.82 seconds. This is an improvement of 88.68%!”
“Cypress executes the tests with a NodeJS process, which orchestrates the tests in the browser where the tests are executed. This also means that the browser execution environment limits the memory available for tests. Due to this, we have faced crashes in between tests multiple times. At one point, the crashes became so frequent that we had to invest a lot of time and energy into finding a solution because no test executions were running to completion.”
Wow! Feel sorry for them. It must be very frustrating.
Cypress: “Architecture prone to flakiness”
“it will cause the test to be flaky. This is because, in Cypress, only queries are retried, not commands.”
What a mess!
Many readers are likely familiar with the "propaganda campaign" by Cypress marketers, claiming that “Selenium is flaky, but Cypress is not.” This couldn’t be further from the truth.
Having developed and maintained tens of thousands of E2E (web) test scripts (for various projects), I can confidently say that Selenium WebDriver remains the most reliable web test automation tool—far ahead of any alternatives. This superiority is inherent: it is a W3C standard and is supported by all major browser vendors.
Cypress: “Misleading simplicity”
“examples are for very straightforward application scenarios that we seldom encounter when working on large projects. When you start automating complex scenarios, things soon get complicated.”
Cypress: Poor “Browser support and support for mobile viewport”
“Since Cypress tests run directly on the browsers, only a few are supported. Until recently, it did not even support WebKit browsers”
They should have thought about this before, right?
Selenium WebDriver offers the best browser support, as all major browser vendors provide drivers for it. I’ve been using the same tech stack—Selenium WebDriver + RSpec—since 2011, and I’ve never had to worry about issues like these.
Cypress: “Lacks the support for multiple tabs and browsers”
“Cypress lacks the support for multiple tabs, so the only way to test these scenarios was to do this long and complicated process: …”
In this case, they can't blame Cypress—they can only blame themselves. Cypress made it clear from the start that it doesn’t support multiple tabs and browser windows.
Cypress: “Random errors during tests due to Cypress's iFrame Execution Model”
“They work by running Cypress as the main page and running the application which is being tested as an iframe within the page. This can lead to a lot of unexpected errors during the test execution.”
The architecture of Cypress decided the supporting iframes with issues. (The early versions of Cypress did not support frames at all, and they made a quite clear about it, Later, it came up with some sort of workaround)
Once again, this isn’t Cypress’ fault—it’s the person who chose it.
Lessons:
E2E test automation has barely changed over the past 14 years. So, there is really NO excuse to fail Web test automation. I have consistently achieved a 100% technical success rate on web test automation for 17+ years, typically automating and running dozens of core business scenarios in a CT process within the first week (and onwards, this is where the real E2E test automation challenge is), effectively detecting regression errors.
Seek advice from a qualified real Test Automation Coach. Save big time and money. If this company had a good mentor, all the costly mistakes could have been avoided.
The facts: Successful people have mentors; Web test automation barely changed over the last 20 years.
I understand many software companies are not willing to spend a cent on seeking external help. In this case, there is still an easy-and-quick process to prevent the “Choosing cypress mistake”. Check out my article: “Test Automation and Continuous Testing Competition Week”.
