A shared suite adapted to each store through five JSON files. Luma, Hyvä and Mage-OS supported out of the box.
npx @samjuk/create-magento-e2e Read the docs on GitHub | guest checkout completes | 4.1s | ok |
| customer account creation | 2.3s | ok |
| add to cart from category page | 1.8s | ok |
| product rename shows in grid and storefront | 6.2s | ok |
| gift message on checkout | not-applicable | skip |
Skipped tests carry a reason code, so platform gaps never hide inside a store lacking the feature.
The installer adds the core package, the package for your theme, and a config directory. Nine packages are published to npm under MIT, currently v0.1.x.
npx @samjuk/create-magento-e2eThey merge in order: core defaults, then the theme package, then yours. Anything you have not moved is inherited.
dev/tests/e2e/config/selectors.jsonThere is no projects array to keep in sync. Install a test package and its tests turn up on the next run.
npx playwright testBoth theme packages expose identical test titles and tags, so one store config behaves the same under either. CI fails if the two drift apart.
Core defaults, then your theme package, then your store. You restate only what you moved. Unrecognised keys pass straight through, which is how a module namespaces its own block rather than earning a sixth file.
config/selectors.json selectors your theme moved config/slugs.json URL keys and route paths config/inputs.json addresses and cards that validate config/fixtures.json products, categories, customers config/features.json what this store has switched on
Any dependency declaring e2eModule.testDir contributes its specs to the next run. There is no projects array to keep in sync.
npm i -D @acme/e2e-m2-module-subscriptions # its specs run on the next pass, no config change npx playwright test
Every exclusion carries a reason code, printed at the start of the run. Without that split, platform debt hides inside a store's legitimate limitations.
Dump and restore, with a flag row written once the dump exists and cleared by a completed restore. A run killed before teardown leaves the flag set, so the next run stops rather than dumping an already polluted database as its only clean restore point.
Write the test once, in the same place as the thing it covers, then opt in per project.
| Source | Where | Enabled by |
|---|---|---|
| Theme suite | @samjuk/e2e-m2-theme-* | config.theme |
| Module packages | @<scope>/e2e-m2-module-* | any dependency declaring e2eModule.testDir |
| Your own tests | dev/tests/e2e/tests/ | always |
app/code modules | app/code/{Vendor}/{Module}/Test/E2E/ | the directory existing |
| Composer packages | vendor/<name>/Test/E2E/ | opt in via config.vendorModules |
A module you reuse across clients ships its tests inside the Composer package. Install the module on the next project, name it in config.vendorModules, and the tests come with it.
No. It is open source under MIT and published to npm as nine packages: a core suite, two theme packages, five module packages and the scaffolder. It was invite-only during the private beta and is not any more.
Magento 2.4.7 to 2.4.9 and Mage-OS, with Luma and Hyvä supported out of the box. Earlier Magento versions are not planned.
It is a security decision. Test code runs with your developer credentials, your CI runner network access and often a live database connection. A suite that executed whatever specs it found in vendor/ would hand arbitrary code execution in your pipeline to every package in your dependency tree. Adding a package to config.vendorModules is a reviewable line in a pull request.
They read state back rather than trusting a success message, because a success message only proves a controller did not throw. An address is saved then re-read from the form. A product rename is checked in the form, in the grid and on the storefront. An order confirmation is matched by increment ID.
If you have one store and want a suite that grows with it, elgentos/magento2-playwright and ProxiBlue/m2-hyva-playwright are both good and involve considerably less machinery. The configuration layers here start paying for themselves once the same suite runs against stores you did not build together.
It is an early release at v0.1.x and it will have edges. Bug reports, overrides you had to write, and anything you could not express in config are all useful, including the view that the whole approach is wrong.