Testing, Deployment and Marketplace

A WooCommerce extension runs inside WordPress, so almost every useful test needs WordPress loaded. The layers differ in how much of the platform they start, and therefore in cost.

Source: WooCommerce docs: Testing

The figure orders the layers of the example plugin by cost, with the times that were measured on the local store. The rule that it encodes is to push every check as low as it can go: a shipping rate is a unit-level test, a REST route needs WordPress, and only a shopper journey belongs in a browser.

The plugin is small on purpose. Its header declares the supported WordPress, PHP and WooCommerce versions (the L-1 policy that the Marketplace also uses), depends on WooCommerce with Requires Plugins, and declares compatibility with HPOS and with the Cart and Checkout blocks, as described on the extension development page.

Source: WooCommerce docs: Extension development best practices

The header keys that matter for testing and for the Marketplace are Requires at least and Requires PHP (WordPress and PHP), Requires Plugins (WordPress 6.5 and later refuses to activate the plugin until WooCommerce is active), and the two WooCommerce keys WC requires at least and WC tested up to. The last one is what the "tested with" notice in the Plugins screen reads, so it has to be bumped when the test matrix moves. The plugin was installed on the local store from the zip built later on this page, activated, and called:

On the same store wp wc hpos compatibility-info listed "Pocket Coffee Testing" among the compatible plugins, which is the check that the compatibility declaration reached WooCommerce.

The first and cheapest check is PHP_CodeSniffer. WooCommerce publishes the woocommerce/woocommerce-sniffs ruleset (standards WooCommerce, WooCommerce-Core, WooCommerce-Core-Tests), which builds on the WordPress Coding Standards (WordPress, WordPress-Core, WordPress-Docs, WordPress-Extra) and PHPCompatibilityWP. The security sniffs are the ones that matter: output escaping, nonce verification, input sanitisation and capability names. The Marketplace code review and the QIT security test look for the same classes of problems, so a clean local run removes the most common reasons for a failed submission.

Source: GitHub: woocommerce-sniffs

The ruleset file is phpcs.xml.dist at the plugin root. It lists the files to check, the minimum PHP version for the PHPCompatibilityWP sniffs (7.4- is the value of Requires PHP), the standard, the text domain of the i18n sniff and the custom capabilities. The last property is needed because WooCommerce adds capabilities such as manage_woocommerce that WordPress itself does not know, and the sniff warns about unknown capabilities.

Source: GitHub: WordPress Coding Standards

On the local store the ruleset (without the capability rule, which this plugin does not need) printed nothing for pocket-coffee-testing, exit code 0. A deliberately bad function showed that the standard is really active: it produced 10 errors and 2 warnings, among them these (the line numbers are those of the bad file):

PHPStan is the other static tool. The QIT runs it as a managed test (run:phpstan, with the level chosen by --phpstan_level) and it needs the WordPress and WooCommerce function stubs to know the platform functions; the stubs are published on Packagist as php-stubs/wordpress-stubs and php-stubs/woocommerce-stubs. PHPStan was not run for this page.

Source: QIT docs: PHPStan managed test

WooCommerce itself, and every plugin that follows its example, tests with PHPUnit on top of the WordPress test library from the wordpress-develop repository. The library provides the WP_UnitTestCase base class, which wraps each test in a database transaction and rolls it back, resets the global state, and offers factories (self::factory()->user, ->post, …​). Because WordPress is loaded for real, there are no mocks of WordPress functions: the plugin code runs against the real hooks, options, REST server and, with WooCommerce activated in the bootstrap, against the real WooCommerce classes and tables. The WordPress test suite and the deployment of a WordPress site in general are covered in Testing and Deployment and CI/CD.

WooCommerce’s own end-to-end and API suites are written with Playwright, so extensions that follow the same stack can reuse the helper package @woocommerce/e2e-utils-playwright. The package is marked as under active development (0.x versions can break), requires Node 24.15 or later in its engines field, and exports four groups of helpers.

Source: WooCommerce repository: e2e-utils-playwright package

A critical flow is a user interaction that has to work for the product to be usable. WooCommerce asks extension authors to identify theirs, rank them, store the list in a permanent place such as a README or wiki, and prioritise end-to-end tests for them while using the list as a charter for manual smoke tests. The Marketplace submission checklist asks that the critical flows of the product "have been thoroughly tested". The core list is a useful template. It is split in two areas, shopper and merchant, and each has many items:

Source: WooCommerce docs: Core critical flows

For the Pocket Coffee plugin the list is short, and each flow maps to the cheapest layer that can check it:

The workflow runs the three jobs in order: the coding standard, the PHPUnit matrix, and the end-to-end suite in wp-env. The matrix follows the L-1 policy, the latest and previous series of WordPress and WooCommerce, and the minimum PHP version of the plugin header together with the version that most sites use. The action versions are the ones current on 2026-10-27 (actions/checkout v7.0.1, actions/setup-node v7.1.0, actions/upload-artifact v7.0.2, shivammathur/setup-php 2.40.0). The file was parsed as YAML (three jobs, a matrix of two PHP, two WordPress and two WooCommerce versions) but not executed, because GitHub Actions is not available on the local stack.

Source: GitHub: setup-php

Pin the WooCommerce versions of the matrix to exact releases and move them with the release cadence (a minor release about every five weeks): latest would make a green build depend on the day it runs. bin/install-wp-tests.sh is the file that wp scaffold plugin-tests generates. The WordPress.org plugin check, WordPress/plugin-check-action, can be added as a fourth job for plugins destined for the plugin directory; it checks the same class of problems as the QIT security and validation tests.

Source: GitHub: Plugin Check action

The Quality Insights Toolkit is WooCommerce’s testing service and the quality gate of the Marketplace: the same managed tests run locally, in CI and when a product is submitted. It consists of a command line tool, woocommerce/qit-cli, which talks to the QIT service and can start ephemeral Docker environments, and the test definitions that the service runs remotely. Using the service requires a WooCommerce.com partner account with at least one Marketplace extension; the documentation does not describe any use without one.

Source: QIT docs: Getting started

Source: QIT docs: Security managed test

Beyond the managed tests, QIT has test packages (custom Playwright suites with a qit-test.json manifest, run with qit run:e2e and published with qit package:publish), ephemeral local environments (qit env:up, qit env:down, qit env:enter, qit env:exec, qit env:reset, with --env and --env_file to pass variables and tunnels for webhooks and payment gateways), saved settings in a qit.json file (named environments, extension sets, test profiles under test_types, and groups that run several profiles with qit run:group), and a comparison of two test runs.

Source: QIT docs: qit.json reference

What ran for this page: the command line tool was installed with Composer (woocommerce/qit-cli 1.3.2, a PHAR-based package that needs the PHP zip extension), qit --version and qit list worked, and before qit connect the tool offers a limited set of commands (connect, blueprint:export, blueprint:import, env:*, partner:add, qit:dir, tunnel:* and woo:validate-zip). The one account-free command that checks a submission, woo:validate-zip, was run on the zip that the packaging section builds:

The validator is shallow. A second zip with the plugin files at the archive root instead of in a folder, and a third that contained one file bad/bad.php without a plugin header, were also reported as valid, so the message must not be read as a pass of the managed tests. The managed tests themselves (qit connect, qit run:*) need the partner account and were not run.

The repository layout of the example is the plugin itself at the root, with the development files next to it. The files that must not reach a customer are described twice, because two tools need them: the .gitattributes file with export-ignore for git archive, and the .distignore file (the format that the WordPress.org deploy action reads, and the wp dist-archive command too, which was not run here) for rsync-based builds.

Source: Git docs: gitattributes

A release is a commit, a tag and a zip with exactly one top-level folder named like the plugin slug. Both builds were run on the example repository:

The commands produced the same single file. The plugin has no Composer runtime dependencies; a plugin that does must run composer install --no-dev --optimize-autoloader before the build and ship vendor, because customers' servers rarely have Composer. Build the JavaScript the same way (npm run build) and ship the built assets, not node_modules. The WooCommerce development guide gives the reason: most WordPress hosting does not include Node or Composer.

There are four common destinations, and the package is the same for all of them.

Source: GitHub: 10up WordPress plugin deploy action

The zip built above was deployed on the local store with WP-CLI, which is the same call that a deployment script makes, and the result was checked with the same commands as a smoke test:

A deployment smoke test for a WooCommerce plugin is short: the plugin is active at the expected version, wp wc hpos compatibility-info still lists it as compatible, the REST route or admin page that the release changed answers, and WooCommerce > Status > System status shows no new errors. After an update of WooCommerce or of the extension, WooCommerce can run database updates in the background through Action Scheduler, so check WooCommerce > Status > Scheduled Actions for failed actions before declaring the deployment done. A rollback is the previous zip: wp plugin install <old-zip> --force. Database changes made by the release (options, tables) need their own downgrade or must be backwards compatible, which is why a release that changes the schema should be tagged as a minor or major version.

These destinations are about shipping a plugin. Running a whole store as stateless containers on several Kubernetes nodes, with a managed database, is a different problem; see Cloud: Deployment Overview and, for the rollout of a release and the WooCommerce database update, Cloud: Releases and Database Updates.

The Marketplace is the curated catalogue at woocommerce.com. The rules below come from the official submission guide, checked on 2026-10-27; the account steps could not be run, because they need an approved vendor account.

Ran on the local WordPress 7.1.3 and WooCommerce 11.2.1 store (PHP 8.3.36, MariaDB 11.8) and its tooling: PHP_CodeSniffer with WooCommerce-Core and PHPCompatibilityWP on the plugin (clean) and on a deliberately bad file (10 errors and 2 warnings); wp scaffold plugin-tests (files listed above); the PHPUnit suite of 7 tests with 19 assertions against a dedicated test database, with a deliberate failure; Playwright with Google Chrome against the store (the three specs passed together in 2.8 s on the first complete run; later runs of the checkout spec failed for the reasons given above); createClient from @woocommerce/e2e-utils-playwright against the REST API; the installation of woocommerce/qit-cli 1.3.2, qit --version, qit list and qit woo:validate-zip; a git archive and an rsync build of the example repository; the installation of the zip with WP-CLI and the smoke checks; the parsing of the workflow YAML and of the .wp-env.json JSON. The checkout test left orders on the shared store, which were set to the cancelled status.

Not run: the QIT test runs and qit connect (a Woo.com partner account is needed), the Marketplace submission and review, wp-env and WordPress Studio (no Docker-in-Docker, and the shared store stayed in use), GitHub Actions, PHPStan and the Plugin Check action, the WooCommerce core PHPUnit and end-to-end suites, WooCommerce 11.3 betas, and the WordPress.org Subversion deployment.