@temporal-contract/testing

---

@temporal-contract/testing / test-rig

test-rig

Variables

START_METHODS

const START_METHODS: Set<string>;

Defined in: test-rig.ts:71

The three ContractClient methods that can start an execution. Pinned against ContractClient's actual method surface by a unit test in test-rig.spec.ts — exported so that test can import it; guarded again at runtime inside testRig itself, since a unit test only catches drift when someone remembers to run it.

Functions

extractStartedWorkflowId()

function extractStartedWorkflowId(methodName, args): string;

Defined in: test-rig.ts:100

Pull the workflowId out of a start method's options bag (its second argument, per every START_METHODS signature) so the rig knows which execution to replay later.

This is the rig's single load-bearing assumption about another package's call shape — held with no runtime enforcement anywhere else. Throwing here when the assumption doesn't hold is deliberate: the alternative is startedIds silently staying empty, onTestFinished iterating nothing, and the test passing green while proving zero replay coverage — exactly the failure mode this whole rig exists to prevent. Pure and exported so the guard is unit-testable without a server.

Parameters

Parameter	Type
methodName	string
args	readonly unknown[]

Returns

string

---

isTerminalStatus()

function isTerminalStatus(name): boolean;

Defined in: test-rig.ts:34

Whether a workflow-execution status names a finished run, and is therefore safe to fetch and replay. An unscoped handle.describe() (no runId) always resolves to the latest run in a chain, so in practice it can never itself report CONTINUED_AS_NEW — that status only ever shows up if a caller describes a specific older run directly. It's kept in the set anyway because it genuinely is a finished, replayable state for whichever run it's read from.

Parameters

Parameter	Type
name	string

Returns

boolean

---

skipReasonFor()

function skipReasonFor(workflowId, allowlist): string | undefined;

Defined in: test-rig.ts:47

Look up the caller-supplied replaySkipAllowlist reason (see RigOptions) for a non-terminal execution, matching by workflow-ID prefix so one entry covers every workflow ID nextTaskQueueId-style counters generate from a shared base (e.g. "probe-edge-cases" matches "probe-edge-cases-1", "probe-edge-cases-2", ...). Returns undefined for anything unlisted, so the caller can fail loudly instead of silently under-reporting replay coverage.

Parameters

Parameter	Type
workflowId	string
allowlist	Readonly<Record<string, string>>

Returns

string | undefined

---

testRig()

function testRig<TContract>(testEnv, options): Promise<{
  client: ContractClient<TContract>;
  worker: TypedWorker;
}>;

Defined in: test-rig.ts:193

Build the worker + client pair every in-process test needs, and register an onTestFinished hook that replays the history of every execution the client started.

The rig deliberately does NOT scope the task queue — callers keep calling withTaskQueue themselves. A same-workflow continue-as-new must land on the contract's static queue, because the contract is closed over inside the bundled workflow module and a test-side copy can never reach it.

consumed from sibling packages' suites via the @temporal-contract/testing/test-rig subpath; the tsconfig paths indirection hides that usage from knip.

Type Parameters

Type Parameter
TContract extends ContractDefinition

Parameters

Parameter	Type
testEnv	TestWorkflowEnvironment
options	RigOptions<TContract>

Returns

Promise<{ client: ContractClient<TContract>; worker: TypedWorker; }>