WordPress / WordPress/block-development-examples
E2E suite silently tests nothing — revive it and run it in CI
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 334
- Forks
- 52
- PR merge metrics
- No merged PRs in 30d
Description
Problem
_tests/e2e/insertion.spec.js derives the plugins to test from the plugins array in .wp-env.json. The local ./plugins/... entries were removed in the repo revamp (f0b9107), leaving only the Gutenberg zip — so pluginsPathsToTest is empty and npm run test:e2e passes with zero tests. E2E is also not wired into any GitHub workflow, so nothing could have caught this: any PR can break a block's build or registration and merge green.
Related rot discovered while auditing:
- All 23 files in
_tests/e2e/__snapshots__/are orphaned — the current spec usestoContain(), not snapshots. One references a plugin that no longer exists (...833d15...). - The spec imports
@wordpress/e2e-test-utils-playwright, which is not a root devDependency; it resolves only transitively through@wordpress/scripts, which is fragile under pnpm (the lockfile contains two different versions of it). plugins/editable-block-1b8c51/e2e/basic.spec.jsuses the deprecated Puppeteer stack and contains assertions that cannot fail (expect( true ).toBe( true );expect( page.$( ... ) )on an unawaited Promise). Seven other plugins declaretest:e2e/test:unitscripts with no test files.
Proposed fix
- Derive the plugin list from the filesystem so it can't rot again: keep
.wp-env.jsonstatic and map the wholeplugins/directory, then activate all plugins via WP-CLI in a Playwright global-setup. The spec walksplugins/*/directly instead of parsing.wp-env.json. - Add a CI workflow that runs the build, starts
wp-env, and runstest:e2eon every pull request and on push to trunk. - Delete
_tests/e2e/__snapshots__/. - Add
@wordpress/e2e-test-utils-playwrightas an explicit root devDependency. - Delete
plugins/editable-block-1b8c51/e2e/and the deadtest:e2e/test:unitscripts from plugins without test files.
Out of scope
- Behavioural coverage (Interactivity API front-end assertions, SlotFill/sidebar/format-api tests) — this issue only restores the insertion smoke-test safety net.
- A purpose-built "e2e testing for blocks" teaching example (possible follow-up, replacing what
editable-block-1b8c51/e2e/gestured at).
Notes for implementers
- wp-env only auto-activates plugins listed in its
pluginsarray; amappingsmount does not activate them — hence the WP-CLI activation step. - Watch for inter-plugin interference with all 30 active at once (several register post-meta UIs and sidebars). If conflicts appear, activation may need to be per-test-group.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running npm run test:e2e and reading _tests/e2e/insertion.spec.js, .wp-env.json, and the package scripts to confirm why no tests run. Then inspect the existing workflow directory and the listed snapshot and editable-block-1b8c51/e2e files. Done means the insertion smoke test runs against the filesystem plugins, the suite is exercised on pull requests and trunk pushes, and the obsolete test assets and scripts are removed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, javascript, playwright
- Domain
- ci-cd, devops, testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100