Migrating from Cypress to Playwright

A team faced growing friction in end to end tests and made a clean comparison of Cypress and Playwright. Opinionated workflows, plugin churn, iframe pain, flaky screenshots, and a paywall on parallel runs had slowed delivery. A shared hackathon with developers and testers produced scripts, timings, and failure profiles. Playwright came out ahead on speed, cross browser support, and control over network and context. Early migration targets the top user flows and production smoke checks. Cookies, A/B flags, and request interception reshaped setup and fixtures. Capacity stays tight, yet the switch highlights a wider point. Tool choice is product strategy.

Podcast Episode: Migrating from Cypress to Playwright

In this episode, I talk with Maciej Wyrodek about moving from Cypress to Playwright. We talked about why Cypress started to work against the team: opinionated style, plugin churn, iFrames, flaky screenshots, and a pricing wall around parallel runs. Maciej's answer was a hands on hackathon with devs and testers. Playwright won. The migration starts with their top 10 flows and production smoke checks.

"There is a lot of our custom admin stuff like managing artworks, managing the copyrights, managing work with the artist. So there is a lot of custom code there. So it's not just simple E-commerce." - Maciej Wyrodek

Maciej Wyrodek is a knowledge seeker, Quality Consultant, Mentor and Trainer - specialised in process improvement, and Test automation.Maciej is always looking for a new opportunity to challenge and hone his skills. He has gathered experience working for different companies with different working models, From small to big corporations, From Product via In-house development to software house. Thanks to that he has a wide perspective on testing quality and delivering value.During his stay in Dublin he realised his passion: Knowledge sharing.His strong belief is that what makes us human is the ability to learn and share knowledge.That is why for the almost decade he has been doing his best to give back to the IT community, by writing articles, recording videos on his channel Itea Morning and speaking on conferences.

Highlights der Episode

• Cypress plugin churn, iFrames, flaky screenshots, and parallel pricing hurt productivity
• A joint hackathon led the team to choose Playwright
• Start migration with top business flows and production smoke tests
• Handle cookies, A B tests, and request interception in setup
• Autonomous testing bots clicked aimlessly and did not help

Lessons in Choosing and Transitioning Test Automation Frameworks

Rethinking Test Automation: When the Tool No Longer Fits

For many engineering teams, Cypress is the default choice for web test automation. It’s popular, easy to learn, and the ecosystem is thriving. But what happens when your growing project starts to chafe against the boundaries of your chosen testing framework?

That’s exactly what happened to Maciej Wyrodek and his team at Displate. On a recent episode of Software Testing Unleashed, Maciej shared how—and why—they made the decision to embark on a substantial migration from Cypress to Playwright, illuminating the process with insights, practical advice, and a few surprising outcomes along the way.

Recognizing When It’s Time for Change

Maciej didn’t take the decision lightly. When he joined Displate, Cypress was already in use for frontend automation, and as the new QA lead, he initially opted to expand its use to backend business systems as well—mainly to avoid rocking the boat. In hindsight, however, he realized that Cypress’s design decisions and strong opinions about how tests should be written weren’t well-aligned with his team’s needs.

As the project evolved, several issues became more pronounced:

• Cypress’s opinionated API and reliance on a growing set of plugins made customizing and maintaining tests difficult.
• Interacting with iframes and certain integration points (like third-party payment providers) proved cumbersome, involving multiple workarounds.
• Issues with visual feedback, such as unreliable full-page screenshots during test failures, made debugging harder.

Beyond technical hurdles, business considerations also played a critical role. The team’s need for affordable parallelization led them to a third-party service, Currents. However, when Cypress took steps that blocked Currents support in newer versions, it eroded trust and pushed Displate to look elsewhere.

Building Buy-In and Charting a Path Forward

Switching frameworks in an active, feature-rich environment is no small feat. The team faced the dual challenge of migrating important automation code while maintaining day-to-day product development and quality assurance.

Their strategy started with clear-eyed reflection: What did they actually use and like about Cypress? What pain points were they eager to solve? From there, Maciej’s team compiled a matrix of requirements—listing must-haves, nice-to-haves, and show-stoppers for any new tool.

A Collaborative Hackathon: Testing Tools, Not Just Features

Rather than basing their decision solely on documentation or vendor pitches, the team organized a hands-on hackathon. Seven candidate tools went head-to-head, each evaluated by small groups (including developers and QA engineers) against ten real-world test case scenarios from Displate’s domain.

What stood out?

Playwright rapidly emerged as the frontrunner—not just for its feature set, but its real-world performance and ease of getting stable tests running.

Some tools lost ground quickly, either due to poor documentation, outdated guides, or failure to handle the practical demands of the team’s workflow.

Experiments with AI-based tools brought some entertainment value—a script that wandered the site at random for minutes before completing a scenario—but weren’t yet reliable enough for production migration.

Importantly, the team ensured alignment by holding a demo at the end of the hackathon. While a few other frameworks performed admirably, Playwright’s combination of flexibility, community, and hands-on results won broad consensus.

Managing the Migration: Top-Down, Iterative, and Realistic

With Playwright chosen, the hard work of migration began. The team prioritized their most critical tests first—the “top ten” end-to-end scenarios essential to business value—migrating them during December’s lull in new feature development. From there, their approach was pragmatic:

• New features’ tests would be written in Playwright going forward.
• Old Cypress tests would be migrated opportunistically—especially when larger refactors or failing tests made it natural to rework them in the new framework.
• Surprises cropped up: certain Cypress features, like API request interception and session management, worked differently in Playwright, sometimes requiring custom utilities or reconsidered approaches.

The Role of AI and Looking Ahead

While hand-coding remains central, the team is experimenting with AI tools like Cursor to aid the migration, translating Cypress code to Playwright and accelerating routine rewrites. Early results are promising, if occasionally unpredictable. Maciej anticipates further AI integration as tools mature.

Will the team finish the migration this year? It depends—resource planning is ongoing, and business needs always come first. Still, with Playwright’s adoption accelerating among both QA and developers, the future of test automation at Displate looks collaborative, maintainable, and full of learning.

Final Thoughts:Maciej’s candid reflections offer practical lessons for any team facing tool fatigue or needing to scale test automation. The key takeaways: understand your context, involve the whole team, test tools in your real-world environment, expect surprises, and continually adapt—whether through process tweaks or emerging technologies like AI.