Testing Strategy
Testing Strategy
Status: Current source practice reviewed; recommendations identified separately.
Last reviewed: 2026-10-17
Scope
This describes configured test practice in the six inspected repositories. It reports no execution result, deployed-system guarantee or approved future policy. Source revisions, complete source counts and separate curated-case counts are in the test inventory.
Current practice supported by source
| Worker | Current approach and environment | Established suite command | Source |
|---|---|---|---|
| Registration | Node.js 22 and pnpm 12.11.2 are selected by CI. Existing dependencies must be available. vitest.config.mts runs the Cloudflare test plugin against wrangler.jsonc; it supplies NODE_CONFIG and TEST_D1_SCHEMA_SQL. tests/setup.ts creates the schema in the test D1 binding db. Registration also needs a REGISTRATION_LIMITER binding. |
pnpm test |
scripts; CI workflow |
| Ingress | CI selects Node.js 22 and pnpm 12.11.2. vitest.config.mts uses the Cloudflare plugin and wrangler.jsonc, replacing Registration and Corpus with controlled service functions. Direct-handler tests also supply their own spies. |
pnpm test |
scripts; CI workflow |
| Corpus | CI selects Node.js 22 and pnpm 12.11.2. vitest.config.mts uses the Cloudflare plugin, a Registration stand-in, test collection/history identifiers and extra simulated D1 databases. tests/setup.ts applies schema.sql and initialises the test history. Selected archive cases also need the test R2 SEGMENTS binding. Protected-route cases require a privately supplied test internal secret. |
pnpm test |
scripts; CI workflow |
| Resources | CI selects Node.js 22 and pnpm 12.11.2. The test directory is test/ and no root Vitest configuration was found. test/worker.test.mjs supplies service stand-ins, NODE_CONFIG, an in-memory caches.default and waitUntil tracking. Ajv checks the produced OpenAPI schema in contract tests. |
pnpm test |
scripts; CI workflow |
| Events | CI selects Node.js 22 and pnpm 12.11.2. No root Vitest configuration was found. tests/pump.test.ts directly calls pump with makeEnv, an in-memory progress value and queue spies, and passes controlled feed responses. No deployed queue/KV or application credentials are needed for these unit cases. | pnpm test |
scripts; CI workflow |
| MCP | CI selects Node.js 22 and pnpm 12.11.2. vitest.config.mts uses the Cloudflare test plugin and requires explicit Registration/Ingress replacements. tests/routing.test.ts fixture() supplies its own KV Map, Ingress spy, public-API fetch spy and OAuth grant/RPC helpers. Direct tool/client/queue tests use separate stand-ins. | pnpm test |
scripts; CI workflow |
Registration, Ingress, Corpus and MCP declare the Cloudflare Vitest plugin. Events uses direct pump fixtures; Resources uses handler/contract tests with an in-memory cache and schema validation. Helper tests, simulated-runtime tests and service stand-ins coexist. Integration does not automatically mean a live service was contacted.
CI selects Node.js 22 and pnpm 12.11.2. The inspected deployment workflows perform code/format/security-related checks and allow default-profile deployment for eligible main-branch pushes, but do not invoke pnpm test or Vitest. Resources additionally runs pnpm openapi:check. Workflow files establish declared practice, not a successful run.
Separate verification scripts include local multi-Worker integration readiness, isolated-consumer build checks and operator archive verification. The last requires protected access and contacts services. None was executed. Configuration checks, dry-run builds and operator checks must not be reported as application-suite executions.
Packaged protocol files are checked against manifests before most suites. Corpus also checks generated payload validators. Resources validates the API built from checked-in source. Some compatibility comparisons depend on sibling sources/documents and can be conditionally skipped; a skipped comparison is not verified compatibility.
Current audit context — 2026-10-19
The 542-entry catalogue below describes the cited revisions. The current inventory supplement records 557 named declarations in 70 files, including local tag-query work and later agent-query tests. Neither count is an execution result. Existing pinned links remain useful historical evidence; use current source and the three specification supplements for changed files.
Complete catalogue and curated review
All 542 named declarations across 69 test files are documented with stable IDs, source links, parameter expressions and directly extracted assertions. The 42 curated scenarios provide deeper requirement/risk analysis and overlap with that catalogue. Neither declaration counts nor static extraction establish runtime instance counts or passing results. Shared helpers and conditional/matrix branches still need semantic review or execution evidence.
How to evaluate evidence
- Begin with a requirement and responsible interface; distinguish desired behaviour from current implementation.
- Read assertions, not just names. Use Partially covered when expected state, calls or response properties are not actually checked.
- Keep implementation and execution status separate using the test-case template.
- Record command, environment, immutable revision, date and output artifact for each run. Until execution evidence exists, use Not run.
- Assert persistence, forbidden effects and recovery only where code, contracts or established invariants define the expectation.
- Treat sequences as ordered positions with possible gaps. Keep per-endpoint pagination, queue acceptance, progress persistence and listener delivery distinct.
Recommended follow-up, not current guarantees
- Decide which suites should be required CI checks; their absence from the inspected workflows is an execution gap.
- Implement the six proposed cases and extend the four partially covered cases in the inventory.
- Add deterministic side-effect and fault assertions at admission, transaction, checkpoint and access-store boundaries.
- Define concurrency, dependency deadline, notification recovery and operational recovery expectations before asserting stronger guarantees.
- Gather coverage reports, historical failure evidence or performance baselines when they support an explicit decision. No numerical coverage or performance target is established by this review.
