Testing strategy

Different suites prove different claims.

The shared API is executed unchanged across runtimes. Node-only tests attack the tooling boundary. A packed-artifact smoke check verifies what npm consumers actually install.

Latest published result

Loading verified status… · latest successful main build · main

Shared · Node Same core suite

Host-neutral API and lifecycle behavior.

Shared · Chrome Same core suite

Real browser, native module, no transform.

Node tooling Integration suite

CLI, configuration, server, timeout, and paths.

Packed artifact Install verified

Clean-project installation and package-name import.

Suite topology

The shared inventory contains 45 unique, narrowly scoped cases: 15 Unit, 10 Functional, 11 Integration, and 9 Regression. That inventory is executed unchanged in both Node and Chrome.

GateRuntimeEvidenceFailure means
Shared categorized inventoryNode 22.12, Node 24, Chrome Stable45 unique Unit, Functional, Integration, and Regression cases from the same source modulesThe public Web-standard API does not behave consistently.
Node tooling integrationNode 22.12 and Node 24Argument parsing, exit codes, result validation, glob matching, configuration, local server safety, timeouts and leaked handlesThe developer-facing CLI or harness boundary is broken.
Native coverage gatesNode 24 and Chrome StableIndependent executable-range, block-range, function-range, and executable-line measurements of index.jsOne runtime did not exercise the complete configured core scope.
Packed npm artifactClean Node 24 projectnpm pack, install the tarball, import package name, run and validate one resultThe repository may pass while the published file set is unusable.
Count unique cases separately from runtime executions.

The four category totals are one 45-case inventory. Node and Chrome execute that same inventory; they are evidence from different hosts, not 90 different cases. Tooling, coverage gates, and package smoke retain their own scopes.

Run tests locally

npm ci
npm test

npm test executes all four shared sets through the thin test/node.js adapter, then runs the Node-only CLI, output, server-security, status-builder, and benchmark-harness tests. Run one shared set directly when narrowing a failure:

npm run test:unit
npm run test:functional
npm run test:integration
npm run test:regression
npm run coverage
# or isolate one collector
npm run coverage:node
npm run coverage:chrome
Check the terminal.

Test output, assertion errors, and collector failures appear there. Use each command's exit status as its automation result.

Chrome coverage requires Google Chrome Stable. The CLI intentionally does not substitute Chromium, Edge, Firefox, or another browser.

What the four shared sets check

Unit · 15 cases

Small contracts in isolation

Exports, EventTarget inheritance, strong-type delegates, strict state, typed public arguments, and delay boundaries.

Functional · 10 cases

Public lifecycle outcomes

Numbered expectations, pass/fail recording, active-test guards, undecided failure, reporting preconditions, and the empty suite.

Integration · 11 cases

Contracts working together

Mixed reports, immutable snapshots, rendered output, subscription-free scheduling, late completion subscriptions, native event-type coercion, cleanup, and isolated instances.

Regression · 9 cases

Earlier fixes stay fixed

Duplicate state integrity, lenient and strict repeat decisions, report identity, log/event deduplication, and post-report sealing.

Interpret the live browser page correctly

The deployed verification page executes the current deployed test/CI.js in your browser. It proves that browser run only. The published status above records the corresponding Node and Chrome CI executions and includes commit and timestamp provenance.

  • A green live page is useful interactive evidence, not a substitute for the CI matrix.
  • A stale deployed page can lag current main; use the CI badge and displayed commit together.
  • Coverage percentages prove execution of the configured scope, not correctness outside that scope.

Benchmark the complete native pipeline

The benchmark is a separate, auditable performance workload—not an inflated correctness-test count. It executes 1,000,000 uniquely named real cases as 1,000 bounded suites of 1,000 in independent Node and real-Chrome lanes, then includes native V8 coverage, validation, JSON, LCOV and standalone HTML report generation, and teardown in the cold-wall result.

npm ci --prefix benchmark
npm run benchmark

# quick end-to-end harness verification
npm run benchmark:smoke

Only the richer built-in node:test runner and pinned Mocha appear as competitors. Raw loops and less capable micro-runners do not enter the visible ranking.

Add the right kind of test

ChangePut the test hereReason
Isolated export, type, delegate, or boundary contracttest/shared/unit.jsOne small contract should fail for one focused reason.
Public lifecycle outcometest/shared/functional.jsExercise behavior through the consumer-facing sequence.
Multiple public contracts working togethertest/shared/integration.jsKeep cross-contract behavior separate from isolated units.
A previously fixed state or idempotence edgetest/shared/regression.jsName the protected behavior without copying it into another set.
CLI, config, filesystem, process, or server behaviortest/tooling.jsThese are intentionally Node-specific host concerns.
Published-file boundaryPackage smoke stepRepository-relative imports can hide packaging defects.

Keep the shared verifier independent of vanilla-test itself as an oracle. Its small Web-standard assertion helpers prevent the framework from certifying its own behavior.