Migrating from Cypress to Playwright: An unexpected journey!
It has always been a debate among engineering teams to use Cypress over Playwright or use Playwright over Cypress? Of course this article will not reveal any new information but I would like to emphasise why we at GWI took the decision to move new projects over to Playwright through real life examples.
While Cypress is a well established framework for e2e functional testing, we got intrigued by the capabilities of Playwright. Playwright is an open-source framework (up till now 😉) developed by Microsoft. What stood out for us was the test pipeline optimisations for greater developer experience, cross-browser testing support and unified syntax. Of course there are more aspects than the above such as technical documentation, parallelisation and sharding, multiple programming languages, unique debugging features etc.
In this article we will present why and how we established Playwright for our Micro-frontend architecture. You will learn a few key benefits of Playwright for a unique developer experience!
The why…
We have already been using Cypress for more than 2 years building an e2e functional test suite for our platform. And after 2 years of continuously running e2e tests on post-deployment phase on staging and production we decided to invest into shift-left testing process.
What our team thought is why don’t we split our e2e tests for the different MFEs and have them running earlier in our deployment pipeline? In this way, we would be able to catch defects sooner, reduce our defect escape rate, and also involve our Software Engineers in contributing to the test cycle effectively.
Having Cypress work in each MFE as a template project was the easy part, but what about scaling our tests in each pull request not to mention in each commit. And there the design phase started to optimise the pipelines. What we followed is a nice approach from the community as we did not want to use Cypress Dashboard to scale our integration tests. This of course is an external solution and the first thing we reviewed when it comes to Playwright (Sharding and Parallelisation).
Pipeline Speed Optimisation
I would start with the out-of-the-box speed and efficiency that Playwright comes with. By default, Playwright runs tests in parallel and strives for optimal utilisation of CPU cores on your machine. In order to achieve an even greater parallelisation, you can further scale Playwright test execution by running tests on multiple machines simultaneously. We call this mode of operation “sharding”.
In Cypress you need an extension to run matrix mode in your CI environment, in Playwright your work is done with just a few configurations!
npx playwright test --shard=1/3
npx playwright test --shard=2/3
npx playwright test --shard=3/3By default, Playwright runs all the tests in order in a single file, but you have the option to run them in parallel as well.
// playwright.config.ts
import { defineConfig } from '@playwright/test';
export default defineConfig({
fullyParallel: true,
retries: process.env.CI ? 3 : 0,
workers: process.env.CI ? 1 : undefined,
});Merging also reports from different machines is something easy to do as it is supported as well from Playwright. To implement all the above in Cypress requires a lot of time and different workarounds from our CI pipelines.
Developer Experience
While using Cypress there is the GUI version available for local development. Although to run a specific test spec, you have to add .only to your test and then revisit the GUI which is rather inconvenient.
Apart from the above I will also define a few key benefits of Playwright when it comes to DX. Firstly, the way to automatically install and setup the tool in just few seconds via VS Code extension is a game changer. Also, the GUI provided for developers contains much more information:
- Tracing providing DOM snapshots
- Google Chrome console, log and network
- Attachments
- Timeline view
Cross-Browser Support
Another issue is the limitations you have when it comes to cross-browser support as Cypress supports Firefox and Chrome-family browsers (Edge and/ or Electron).
Playwright supports Chromium, Firefox, Webkit-like browsers like Safari and Edge. The integration with Selenium Grid is also a plus if you want a dedicated remote infrastructure at your disposal!
Recording Network Requests
Although Cypress works well with MSW to mock your network requests, if you have a vast number of tests to deal with you may need a built in functionality to record responses as fixtures and provide them in your test execution.You can certainly do that in Cypress with external libraries (not built-in support though), but when it comes to Playwright it is a built-in feature that records requests to HAR files and replays them from the files during execution.
New Projects Design
The migration process is even easier when you used abstractions in your testing environment. We just implemented Page Object Model in Playwright and changed the test body format. If you want existing projects (which was not the case for us) you can use GitHub Copilot to migrate test case format to Playwright.
VS Code Extension can prepare the configuration files even the basic CI pipelines for you. From there we created typescript classes to deal with Page Object Design approach hiding Playwright APIs from the actual test suites. The usual…
Conclusion
Cypress is undoubtedly a great tool, but migrating to Playwright has led us to an improved developer experience and faster E2E test execution for us. We have found Playwright to be a powerful tool with its support for parallelism and sharding, mocking, and cross-browser testing support.
