description	kind
jsdom slot test runtime for browser feature specs, for test authors exercising slots, stores, and rendering against production machinery.	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.

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 — mount fails loud with the missing names; provide() them first.
A render is attempted before declare — renderSlot fails 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.

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`	`SlotTestRuntime` assembly, `TestRoot`, auto frame, `mount`/`dispose`
`src/sessions.ts` + `src/workspaces.ts`	`ISessions`/`IWorkspaces` test doubles and `FixtureSession` behavior stubs
`src/fixtures.ts`	Plain fixture builders: conversation snapshots, workspace list state
`src/snapshot.ts`	DOM snapshot serializer (class-hash folding, `<svg>` fingerprint)
`src/remote.ts`	`TestRemote` double for host RPC
`src/translate.ts` + `src/locale-env.ts`	Translation and pinned-browser-language test helpers
`src/settings-scope.ts`	`stubSettingsScope` with test-driven publications and a write spy
`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 SlotRegistry contract 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 — sessionSnapshot contains only Session Controller state, conversationSnapshot contains target-neutral Conversation state, and chatSnapshot contains Chat target state. Assembly tests provide Session event entries instead of adding Conversation or Chat fields to SessionSnapshot.

Dev Note

Working context for maintainers — click to expand

None.

README.md