Testing

Testing

The project uses a test pyramid: unit tests for pure logic, integration tests against a real WordPress database, and a small end-to-end layer in a real browser. Every Composer command below is defined in composer.json; the lab, browser and asset checks use their own entry points. The authoritative policy is docs/en/TESTING.md.

Test layers

Layer	Location	Tooling	Scope
Unit	tests/Unit/	PHPUnit 9.6, Brain Monkey, Mockery	Domain, crypto, policy, contracts
Integration	tests/Integration/	wp-phpunit/wp-phpunit	Boot lifecycle, $wpdb tables, rotation atomicity, owner locks, multisite, privacy
Contract base case	tests/Contract/	PHPUnit	Shared assertions for AbilityPack and AbilitySpec compliance, used by the pack suites
E2E / accessibility	tests/E2E/	Playwright, @axe-core/playwright	Profile and admin UI, WCAG 2.2 AA signals
Packaging	tests/Packaging/, bin/	Bash fixtures	Release ZIP contents and exclusions

Coverage targets are enforced by .github/scripts/CoverageGate.php (ADR-0019): at least 90% for Domain, Auth and Policy, at least 80% combined per pull request, at least 70% per integration suite, and no regression below the recorded baseline. Documentation-only pull requests are exempt and never report a measurement (docs/en/TESTING.md).

Command matrix

Command	Runs in	What it proves	What it does not prove
composer check	Local	PHPCS/WPCS, PHP 7.2 bootstrap syntax, PHPStan level 8, version consistency, repository invariants, the unit suite, documentation drift and the skill-pack validator all pass on this revision	Runtime behavior, integration, hosted CI, production
composer test:unit	Local	Pure domain, crypto and policy logic passes with no WordPress runtime	Database, REST, MCP transport, permissions in a real site
composer test:integration	Shared lab toolbox (CI: wp-env)	Real WordPress boot, tables, migrations, rotation transactions and multisite harness	HTTPS MCP calls, browser UI, real clients, production
composer test:network	Shared lab toolbox	The multisite network path against real network tables	Single-site behavior, HTTP guards, UI
composer test:http	Shared lab toolbox	Origin, TLS, authentication, rate-limit and status-code behavior over real HTTP	Client SDK compatibility, load capacity, UI
composer test:packaging	Local	The ZIP verifier accepts a valid archive and rejects missing or excluded files	That the packaged plugin activates or behaves correctly
composer build	Local	Packaging regressions pass, the ZIP builds, and its structure is verified	Publication, directory acceptance, installed-site behavior
Agent asset checks	Local	Local MCP test/debug assets have the required structure and pointers	That any agent followed them, or that a run passed
Browser E2E	Shared lab browser	Real browser flows, focus, contrast and axe signals on disposable sites	WCAG conformance, real-client compatibility, production

Local commands in detail

composer check expands to lint, lint:bootstrap, analyse, check:version, check:repo, test:unit, check:docs, check:skills (composer.json). It is the gate a contributor runs before review and the same aggregate CI runs in its quality job. check:repo runs the repository invariants in bin/check-repo-invariants.sh, including its self-test; check:skills validates the public skill pack with bin/check-skills.py.

composer check
composer test:unit          # PHPUnit with phpunit.xml.dist
composer test:packaging     # tests/Packaging/verify-zip.sh
composer build              # test:packaging, then bin/build-zip.sh

composer test:packaging builds a synthetic archive, asserts the verifier accepts it, then removes src/ and injects each excluded path in turn, asserting rejection. It starts no service (tests/Packaging/verify-zip.sh).

Lab commands in detail

bin/test-integration.sh validates XNETVN_TEST_MULTISITE as 0 or 1, then either runs wp-env when CI=true or delegates to the lab toolbox through rtl.py. The lab runner accepts only 6.9 and 7.1.2 (infra/remote/run-integration.sh).

composer test:integration                 # WordPress 6.9, single site
composer test:integration -- 7.1.2        # current-stable fixture
XNETVN_TEST_MULTISITE=1 composer test:integration -- 6.9
composer test:network
composer test:http

composer test:network runs bin/test-network.sh, a thin wrapper that delegates to infra/remote/run-network.sh; that script refuses to run outside the guarded lab (XNETVN_RTL=1) and uses phpunit.network.xml.dist. composer test:http runs the HTTP matrix directly in the lab toolbox and writes boolean/status-only results; its fixture creates random disposable users and keys, keeps credentials in a private state directory, and cleans up bound resources on normal exits (docs/en/development.md).

Browser suites use the Playwright configuration for the lab and one --base-url per site, taken from the lab handoff — never a production URL and never committed:

npm run test:e2e
# focused tag, one site at a time
npx playwright test --config=tests/E2E/playwright.remote.config.js --grep UI-OV

UI-FX, UI-COM, UI-OV, UI-TL, UI-KY, UI-AC, UI-ST, UI-HP and UI-NT map one-to-one to tests/E2E/ui-*.spec.js. A focused tag never replaces the full acceptance run, which is tests/E2E/admin.spec.js plus every ui-*.spec.js (docs/en/TESTING.md). The network acceptance group adds /ui-second/ on the canonical network domain.

Agent asset checks

These are project-local structural checks, not product tests:

python3 -I -B .agents/evals/check-test-debug-assets.py --stage all --self-test
python3 -I -B .agents/evals/check-client-assets.py --self-test

They validate skill links, scenario fixtures and client pointers under .agents/. Passing them is structure evidence only; it never authorizes a run and never proves agent compliance (AGENTS.md, .agents/instructions/mcp-test-debug.instructions.md).

Reading results honestly

• A green composer check is a statement about static analysis and unit logic on one revision. It is not integration evidence.
• An integration pass is not an MCP end-to-end pass; only real HTTPS calls through the installed adapter count for that.
• Axe results are signals. They never establish WCAG 2.2 AA conformance, which still needs manual, keyboard and screen-reader review.
• The last recorded P13 acceptance (2026-11-04) is 198/198 on both single sites and 6/6 on network main and child, across Chromium, Firefox and WebKit. That record covers one revision; a later revision needs its own run (docs/en/TESTING.md).
• Hosted CI, real MCP desktop clients, host behavior and production readiness remain separately evidenced. Local success never implies them.

Record every run with time, revision, site, browser, role and command. Keep credentials, hashes and argument values out of logs and artifacts. See Operations for the runtime signals these tests exercise, and Contributing for which checks a pull request must show.