The Test Team helps manage testing and triage across the WordPress ecosystem. They focus on user testing of the editing experience and WordPress dashboard, replicating and documenting bug reports, and supporting a culture of review and triage across the project.
Date: January 20, 2022. We held a meeting to explore the feasibility of migrating to Playwright for e2e testing in WordPress Core and in Gutenberg. Participants: @juhise, @boniu91, @kevin940726, @isabel_brison, @worldomonation @monikarao, Andrey Lushnikov, @mxschmitt. Playwright migration proposal: https://docs.google.com/document/d/1HLXztqHNMZ95kOy8nPFJ9qdiQGiKGvexwHaJQACP_GQ
What are the things the test team is looking for that the current stack (Puppeteer + Jest) does not provide
- Auto waiting mechanism
- Stable APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.
- Stable tests
- A maintained test runner: WordPress currently maintains it owns version of Jest runner
- Better debugging tools
These are things that either miss on our current e2e tests stack, or are not straightforward to have; and that Playwright offers out of the box.
MigrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. methodology
There are two different methodologies that can be used to migrate to Playwright.
- Create parallel packages that will contain the tests with Playwright. For example
e2e-tests-utils-playwright. This method has the advantage of having a clean separation between the tests with the old stack, and the new tests. On the other hand, it will mean maintaining four different packages for the tests and can quickly become difficult to manage.
- Implement the new tests in the existing packages. For example, for the
buttons.test.jstest, have another
pw-buttons.test.jsfile. This method avoids creating new packages.
The general recommendation is to use the second option.
We have found it best to start the implementations only after the release of WordPress 5.9 which is on January 25th.
This recap will be mentioned in the next WordPress test team meeting. Depending on the feedback we get, we will start the process according to the roadmap included in this document.