Unit tests are great for isolated logic, but they won’t tell you whether your block editor UI is falling apart. I have seen too many plugins pass PHPUnit cleanly and then white-screen on the front end because of a React race condition or a malformed block binding. If you build for the modern editor, WordPress E2E Tests are no longer optional. They are your insurance policy against embarrassing client calls.
For years we wrestled with Puppeteer. It was flaky and hard to debug. Playwright is where the ecosystem has landed, and the practical wins are better test isolation and locators that hold up as markup shifts. It pairs well with the official WordPress test utils too, once you get past the initial configuration.
What manual testing actually costs you
Every time you ship a feature you probably spend 20 minutes clicking around the dashboard to confirm you didn’t break the block inserter. That is time you are billing for, or time you are simply losing. I worked out years ago that manual regression testing was my bottleneck. Automating those flows is what lets me refactor legacy code without flinching. If the tests pass, it ships.
If you are still not sold on the setup cost, I wrote about why you should stop guessing and start testing. It is a mentality shift more than a tooling one.
Setting up the environment with wp-env
Reliable WordPress E2E tests need a predictable environment. wp-env is still the default choice because the core team maintains it. I have also had Docker ports collide and stale transients hand me a false failure, so I start from a clean slate every time.
{
"$schema": "https://schemas.wp.org/trunk/wp-env.json",
"themes": [ "." ],
"lifecycleScripts": {
"afterStart": "wp-env run cli wp theme activate $(basename \"$PWD\")"
}
}With the environment running, install the Playwright dependencies. Don’t skip the system binaries: npx playwright install --with-deps, or CI will fail.
Testing block variations and bindings
Block variations are where E2E testing in WordPress earns its keep. Say you have a “Book Author” block bound to post meta. Checking that by hand means creating a post, hunting down the block, setting the meta, then loading the front end. Playwright lets you script the same loop as an “Arrange, Act, Assert” (AAA) test.
Rather than clicking through every UI toggle, use the REST API to set up your state. It is faster and much less fragile. This is the shape I use for a custom meta-bound block:
import { test, expect } from '@wordpress/e2e-test-utils-playwright';
test( 'Displays book review meta on the frontend', async ( { page, requestUtils } ) => {
// Arrange: Create post via REST API shortcut
const newPost = await requestUtils.createPost( {
status: 'publish',
title: 'Senior Dev Guide',
content: '<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"core/post-meta","args":{"key":"themeslug_book_author"}}}}} --><p></p><!-- /wp:paragraph -->',
meta: { themeslug_book_author: 'Ahmad Wael' },
} );
// Act: Navigate to the front end
await page.goto( `?p=${ newPost.id }` );
// Assert: Verify visibility using accessible locators
await expect( page.getByText( 'Written by Ahmad Wael' ) ).toBeVisible();
} );ARIA snapshots instead of raw HTML
Asserting on every <p> and <div> in a complex pattern, say a full “Book Review Card”, is miserable to write and worse to maintain. Use an ARIA snapshot. It captures the accessibility tree, so you still check the structure without the brittleness of a raw HTML snapshot.
If you want to push this further, my guide on Mastering WooCommerce Testing Tools scales the same ideas to e-commerce.
If WordPress E2E tests are eating your dev hours, hand them to me. I have been wrestling with WordPress since the 4.x days.
Cover the critical path, not every edge case
E2E tests are slow next to unit tests, so don’t try to cover every edge case with them. Cover the critical path instead: can a user check out, and does the main block pattern render? Get those green and you will sleep better.
For further reading, the official Playwright documentation is worth your time, and so is the WordPress E2E Test Utils source on GitHub. Watching how the core team handles block navigation taught me more than any tutorial did.
