Testing strategy

When to use it

Plan, write, debug or review WordPress tests: choose the layer (unit, WP integration, REST/AJAX, WooCommerce HPOS, Playwright), prove a regression fails first, fix flaky or order-dependent suites, CI exit propagation and skipped tests. Use for PHPUnit, wp-env and browser test strategy.

Boundaries and hand-offs

This skill decides what to test, at which layer, how to isolate it and whether the run proves anything. Domain correctness belongs to the owner skill (wp-devkit-security-review, wp-devkit-woocommerce-dev, wp-devkit-rest-api-development, wp-devkit-block-development, wp-devkit-accessibility-review). Static typing is wp-devkit-phpstan-review; pipeline design is wp-devkit-ci-cd-and-release-engineering. Use this skill when the question is "does a test exist that would have caught this?".

Ask Claude

With the plugin loaded, start a read-only review of a bounded target:

/wp-devkit:test-review <target-path>

The short form /wp-devkit:test requests a quick scan.

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. Replace the target with your files or journey.

$wp-devkit-test-strategy
Review the target without editing files.
Read the project instructions and the skill's engineering contract first.
Separate confirmed findings from candidates and state the evidence and checks you could not run.

What it covers

The agent loads only the reference that matches the task:

• browser-and-e2e-tests.md : Browser and end-to-end tests
• ci-and-evidence.md : CI reliability and evidence
• test-layers-and-setup.md : Test layers and setup
• test-strategy-workbook.md : Test strategy workbook
• woocommerce-and-data-tests.md : WooCommerce and data-heavy tests
• wordpress-test-recipes.md : WordPress test recipes

How a review runs

1. State the observable behavior and the failure the regression must distinguish. Find the real runner and how failure reaches the CI exit status.
2. Pick the cheapest layer that still contains the failing boundary ( references/test-layers-and-setup.md ): pure unit, WP integration (hooks, capabilities, storage, REST, AJAX, cron, HTTP), browser journey, or manual check. A mock that replaces the failing boundary proves nothing about it.
3. Define controls: a positive case, the denied/invalid/empty/failed-dependency case, and repeat, concurrency or migration cases when promised. Assert persisted state and side effects, not only the response.
4. Check isolation: test-owned data, reset of globals, current user, options, transients, cron, object cache, files, multisite state; no dependence on order or the clock.
5. Check reliability: no arbitrary sleeps, no silent retries or skips, .only blocked in CI, exit codes propagated, skipped tests listed, required checks cannot be disabled by a flag.
6. Report: suitable layer, the regression that fails before the fix, controls, runner and versions, what is not covered. Read references/test-strategy-workbook.md first for decision rules, false positives and the finding format.

What you get back

Lead with the verdict and scope: behaviors reviewed, layers present, runner and versions found. For each confirmed gap give: behavior and file:line, why current tests would pass while it is broken (mock boundary, missing negative case, shared state, swallowed exit), impact, confidence, the proposed regression (layer, fixture, steps, assertions on persisted state), and how to prove it fails first. Separate confirmed gaps, candidates needing execution, and insufficient evidence. For implementation add files changed, commands with exit codes, before/after results, skipped or unavailable checks, and residual risk.

Where to go next

Use review to fix for a bounded implementation and Doctor and reports for environment and evidence tooling.