How we test
Every check can fail
A test that can’t fail proves nothing. Wherever a check could pass by accident, it has a twin: a case that must come out the other way, so a broken feature turns the suite red.
462 checks
Run on every release, from the cryptography of the test agent up to the merchant’s reports.
Two versions of WordPress
The newest WordPress with the newest WooCommerce, and the oldest we support: WordPress 6.8 with WooCommerce 10.0.
Real HTTPS
The protocol is HTTPS-only, so the tests are too. There is no “allow HTTP” switch that could ship by mistake.
What the suite runs
- A real store. WordPress, WooCommerce and MySQL in containers, with real customers, products and orders.
- A test agent. Its own keys and published metadata, signed assertions and proofs, checked against published test vectors.
- The whole protocol, as the agent. Discovery, Sessions, the API, the cart, and a customer’s browser checking out through WooCommerce’s own checkout.
- Real sign-ins. Customers log in through WordPress’s own login page and approve on the consent page. Then their access is ended by disconnecting, by a password change and by a role change, and the tests confirm it’s gone.
- The agent’s browser. One cart across the API and the website, and every page it must be refused.
- Operations. Five confirms sent at once must produce exactly one refund.
- MCP. A stock MCP client signs in through MCP’s own flow, and its token is refused everywhere else.
- Insights. A week of seeded traffic must reproduce exact totals, to the penny.
- The free build. The plugin as published, with Pro removed, is tested to have none of Pro’s routes.
- Nothing logged. Any PHP warning, notice or deprecation during a run fails it.
Every one of these runs before a release ships. The changelog lists what each release changed.