Skip to main content
A workflow is code, so it gets tests. nika test <file> runs the workflow under the mock provider — offline, deterministic, zero keys, zero tokens — and compares the typed outputs: against a golden file (<file>.golden.json) committed next to it. Same idea as snapshot testing: pin what the workflow produces, and any future edit that changes the contract fails loud in CI.

​
Why the mock makes this possible

nika test swaps every infer: / agent: call to the mock provider, whatever model: the file declares — your ollama/llama3.2:3b (or mistral/…, or any cloud model) workflow tests offline, unchanged. The mock is not a stub that returns "ok". It is schema-conformant: when a task declares a schema:, the mock synthesizes an instance that validates against it — required fields present, types respected. Every schema workflow runs offline, end to end, through the same runtime, bindings, and typed-outputs validation as a live run.
triage.nika.yaml
The golden pins the workflow’s outputs: block — a workflow without one pins {}. Declare typed outputs: and the golden guards the whole callable contract.

​
The golden lifecycle

First run — no golden exists yet, so nika test teaches instead of guessing (exit 3):
Create it with --update, review it once, commit it:
The golden is small, readable JSON — the mock-synthesized, schema-conformant outputs:
triage.nika.yaml.golden.json
From now on nika test compares. A match is exit 0; drift renders a per-path diff and exits 1:
If the drift was intended (you changed the schema, added an output), re-pin with --update and commit the new golden — the diff shows up in code review, exactly like a snapshot test.

​
Exit codes · the CI contract

nika test refuses to run a dirty file the same way nika run does: a workflow with check findings exits 2 before anything executes.

​
Wire it into CI

Offline and deterministic means no keys in CI, no flakes, no spend:
.github/workflows/nika-test.yml (fragment)
Commit the *.golden.json files in the same directory as the workflows they guard. A PR that edits a workflow either keeps its golden green or shows the re-pinned golden in the diff — both are reviewable.