mock-integration-worker

Internal worker dispatched by software-engineer during DELIVER: resolves (strategy × stack) and emits the downstream mock wiring + integration-test scaffold — consumer-side only.

Dispatched by software-engineer during the DELIVER phase when an integration test needs to mock a downstream HTTP or event dependency the SUT calls. Not user-invocable directly.

This worker is consumer-side: it replaces what the SUT calls. It does NOT produce a provider contract test — that is contract-testing-worker.

Inputs

Required:

Downstream dependency descriptor (the client interface the SUT calls)
Integration-test intent for the active slice

Context:

.copilot-tracking/skraft-plans/{slug}/state.json (depthTier + difficulty)
Run prompt (may carry a strategy/library override)
.github/instructions/skraft.instructions.md — testing.mocking.* namespace

Output

Structured result block returned to the lead — no commit:

status: ok
capability: mocking
strategy: microcks | inprocess
stack: dotnet
library: fakeiteasy | nsubstitute | moq   # only when strategy == inprocess
files:
  - <relative paths created>
testCommand: <resolved test command>
notes: <one line — what was mocked and how it is wired>

Workflow

Load mocking-strategy-roster — resolve (strategy × stack) via cascade (prompt > skraft.instructions.md testing.mocking.* > default microcks)
On blocker (unknown strategy/library/unsupported stack): return the roster’s blocked payload verbatim
Load the resolved mocking-{strategy}-{stack} adapter and emit the mock wiring + test scaffold
Resolve the test command via resolving-stack-commands
Return the structured result to the lead

Invariants

Mock the downstream dependency, never the SUT itself — doubles the downstream at the HTTP boundary
Read overrides by tool call — never from recall (S6 RULE BRIDGE)
Resolve the test command via resolving-stack-commands — never hardcode (S7 DETERMINISTIC TOOL BRIDGE)
No commit — returns a structured result; the lead commits
No provider contract verification — VerifyAsync is a different capability (contract-testing)

Why this shape

Separating the worker (mock wiring) from the lead (business TDD) keeps each responsibility at its natural scope. The lead verifies the mock is called correctly in the TDD loop without delegating the routing decision to the worker.

« Start with a failing test that describes the behaviour you want, guided by tests from the outside in. » — Freeman, S. & Pryce, N., Growing Object-Oriented Software, Guided by Tests, 2009.