@hrhgit/dsh-test

English | 中文

@hrhgit/dsh-test provides the standalone dsh-test CLI for isolated Web test runs. A run owns its workspace, persistence root, browser session, assertions, and evidence directory. Browser actions drive the UI, while Session, RPC, service, and filesystem assertions verify authoritative effects.

This package is an external test controller, not a Cordis plugin. It intentionally has no dsh.plugin or dsh.bundle manifest and is not mounted in a production profile.

The package is not part of the default dsh-base or dsh-web-app bundles. A test host explicitly composes the real Web scaffold and mounts local plugins through public configuration overlays.

dsh-test run start --host-module ./my-web-host.mjs --json
dsh-test run status --run <run-id> --host-module ./my-web-host.mjs --json
dsh-test run stop --run <run-id> --host-module ./my-web-host.mjs --json

Workflow files provide resumable command sequences. Each command carries a run identity and idempotent request identity, and each response uses the versioned JSON envelope exported from @hrhgit/dsh-test/protocol.

Host modules

--host-module <path-or-package> explicitly loads an ESM module for one CLI invocation. The module exports createComposition(context) directly, as default.createComposition(context), or as testHost.createComposition(context). Its returned TestComposition receives the persisted manifest for every lifecycle hook, so a fresh CLI process can reconnect from runDir, persistenceRoot, baseUrl, and processId.

Host commands normally produce scenario-verified responses. To return renderer-verified, a host must also return an evidenceManifestPath inside the run's evidenceDir. The manifest must contain non-empty ARIA snapshot, screenshot, console, network, and fully passing assertion evidence, or the CLI rejects the verification upgrade.

The repository's real Harness Web adapter lives at apps/web/tests/dsh-test-host.ts. It starts the real Web scaffold and headless Chromium in a separate process, uses dynamic ports for both Web and control servers, and records baseUrl, runtimeId, and processId in the run manifest. run resume reconnects through the run-owned runtime state file, restarting with the same isolated profile and persistence directory only when the original process is gone.

The unified model-center workflow uses a local OIDC/New API fake and reads no real account or network credentials:

node lib/cli.js run start --host-module E:/_workSpace/_Agents/deepseek-harness/apps/web/tests/dsh-test-host.ts --retain --json
node lib/cli.js workflow run --file scenarios/model-center-unified-entry.workflow.json --run <run-id> --host-module E:/_workSpace/_Agents/deepseek-harness/apps/web/tests/dsh-test-host.ts --json
node lib/cli.js run stop --run <run-id> --host-module E:/_workSpace/_Agents/deepseek-harness/apps/web/tests/dsh-test-host.ts --retain --json