README.md 7.8 KB
description: "jsdom slot test runtime for browser feature specs, for test authors exercising slots, stores, and rendering against production machinery."
kind: "package-library"
@deepseek-ai/dsh-client-test-runtime
English | 中文
Summary
dsh-client-test-runtime gives a browser feature spec a real jsdom test bench: it assembles a Cordis context, the renderer-owned slot registry, and the production UiSession adapter around typed Session and Workspace Controller doubles. Feature suites exercise declaration, registration, scoping, stores, injection, rendering, updates, and disposal without copying production renderer or adapter logic. Suites publish Session lifecycle state, Workspace state, projection values, and Conversation events through typed fixtures, then use local DOM snapshot roots, scoped Testing Library queries, and fail-loud service checks. It is not part of the product plugin graph (no dsh.client); feature packages depend on it in devDependencies only.
Table of Contents
- Use this package
- Understand the implementation
- Further Exploration
- Model Experience
- Known Limitations and Deferred Work
- Dev Note
Use this package
This package gives a browser feature spec a real runtime to mount against: create the bench, declare the slots your feature occupies, mount the feature plugin, render a slot, assert on the local view, and dispose — with no second implementation of production logic.
Setting up a feature spec
SlotTestRuntime.create() assembles the runtime, declare(children) registers an auto frame whose per-key <div data-slot> wrappers become snapshot roots, mount(plugin) runs the feature on a real fiber, and renderSlot(key, owner) returns the slot-local view with scoped queries and in-place updates:
const runtime = await SlotTestRuntime.create()
await runtime.declare({ 'feature-slot': {} })
const handle = await runtime.mount(FeaturePlugin)
const view = runtime.renderSlot('feature-slot', { owner: props })
expect(view.container).toMatchSnapshot()
await runtime.dispose()
mount prechecks required services and fails loud when one is missing — provide(name, value) supplies an extra service first. storeOf(key, scopeKey) returns the live store instance the renderer hands a slot's component for identity and action-driven-write assertions.
Local DOM snapshots
A registered snapshot serializer folds CSS-module class hashes (_frame_a1b2c3 → frame) so .snap files stay structural, and collapses <svg> internals to a data-content fingerprint. Suites needing a custom page frame use root.declare(children, Frame) instead of the auto frame; dispose() tears down views, feature fibers, minted scopes, and persisted store state on one axis and is idempotent.
When to use it
Use the bench for feature suites that exercise slots, stores, rendering, and disposal under a real runtime — the production SlotRegistry, renderer, and provide-bundle materialization are mounted, never reimplemented. It is browser-side test infrastructure: it never reaches a model request, and feature packages depend on it in devDependencies only.
What can go wrong
- A declared service is not provided —
mountfails loud with the missing names;provide()them first. - A render is attempted before
declare—renderSlotfails loud; declare the key first. - A spec calls an unstubbed verb on a session behavior stub — fixture stubs fail loud by design, so a missing stub surfaces at the call site rather than silently passing.
Understand the implementation
Implementation internals — click to expand
This section explains the design of the bench; the observable behavior is fully covered in [Use this package](#use-this-package). ### Design The bench copies no production logic: it mounts the production `SlotRegistry`, production renderer, and `UiSession` adapter. `TestSessions` and `TestWorkspaces` implement the owner interfaces that features consume through Cordis, each fixture Session implements `SessionFace`, and `stubSettingsScope` implements `SettingsScope`. `UiSession` derives standard renderer sources from those Controller bindings. Unstubbed `ISession` behavior fails with the missing method name. ### Source map | File | Role | |---|---| | [`src/index.ts`](src/index.ts) | `SlotTestRuntime` assembly, `TestRoot`, auto frame, `mount`/`dispose` | | [`src/sessions.ts`](src/sessions.ts) + [`src/workspaces.ts`](src/workspaces.ts) | `ISessions`/`IWorkspaces` test doubles and `FixtureSession` behavior stubs | | [`src/fixtures.ts`](src/fixtures.ts) | Plain fixture builders: conversation snapshots, workspace list state | | [`src/snapshot.ts`](src/snapshot.ts) | DOM snapshot serializer (class-hash folding, `` fingerprint) | | [`src/remote.ts`](src/remote.ts) | `TestRemote` double for host RPC | | [`src/translate.ts`](src/translate.ts) + [`src/locale-env.ts`](src/locale-env.ts) | Translation and pinned-browser-language test helpers | | [`src/settings-scope.ts`](src/settings-scope.ts) | `stubSettingsScope` with test-driven publications and a write spy | | [`src/invariant.ts`](src/invariant.ts) | Invariant companion (no runtime invariant; the mounted production packages own theirs) | ### Lifecycle `create()` builds a fresh context, mounts the slot and conversation registries, installs the renderer, and provides the session/workspace doubles. `mount` checks every declared injection against the context before starting the fiber, so a missing provider fails loud instead of suspending forever. `dispose()` unmounts React trees first, then disposes feature fibers, releases the root registration, disposes minted session scopes, and clears persisted store state; every public mutator is act-wrapped, so tests never handle SlotCore microtask batching or React `act` themselves.Further Exploration
Read these pages when the package-level contract is not enough. They move from the bench to the production machinery it mounts and the tests that use it.
- ui-session — the production adapter that derives standard Slot sources from the Controller doubles.
- UI slots package — the
SlotRegistrycontract the bench mounts. - UI renderer package — the renderer the bench installs.
- Testing policy — the coverage tiers and browser snapshot lane.
- Test-support group map — sibling harnesses and support packages.
Model Experience
None, as this package is browser-side test infrastructure; nothing here reaches a model request.
KV Cache effect
None; this package neither assembles nor sends a provider request.
Known Limitations and Deferred Work
These limits define how the bench is consumed. They are current package constraints, not a task backlog.
- Vitest and jsdom only — every consumer is an in-repository browser-oriented Vitest suite. The package is not a product plugin or a general Node test harness.
- Session, Conversation, and Chat fixtures stay separate —
sessionSnapshotcontains only Session Controller state,conversationSnapshotcontains target-neutral Conversation state, andchatSnapshotcontains Chat target state. Assembly tests provide Session event entries instead of adding Conversation or Chat fields toSessionSnapshot.