@keystrokehq/cli 0.0.88 → 0.0.90
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -52,7 +52,7 @@ keystroke workflow runs get signup-pipeline <run-id> --include steps,trace
|
|
|
52
52
|
|
|
53
53
|
## Testing
|
|
54
54
|
|
|
55
|
-
Unit-test through `executeWorkflow` from `@keystrokehq/workflow` — never call `workflow.run(...)` directly (skips validation + action context). Stub costly actions by seeding a `
|
|
55
|
+
Unit-test through `executeWorkflow` from `@keystrokehq/workflow` — never call `workflow.run(...)` directly (skips validation + action context). Stub costly actions by seeding `step_completed` events in a `MemoryEventLog`. See [testing.md](references/testing.md).
|
|
56
56
|
|
|
57
57
|
## Next references
|
|
58
58
|
|
|
@@ -46,25 +46,31 @@ it("runs the pipeline", async () => {
|
|
|
46
46
|
|
|
47
47
|
Deterministic actions (pure logic, no network/LLM) need no mocks — run the workflow and assert.
|
|
48
48
|
|
|
49
|
-
## Stub expensive actions by seeding the
|
|
49
|
+
## Stub expensive actions by seeding the event log
|
|
50
50
|
|
|
51
|
-
Before running a step
|
|
51
|
+
Steps are checkpointed in the durable event log as `step_completed` events keyed by a stable **correlation id**. Before running a step the action runner checks the log for that correlation id; pre-seed a `step_completed` event to skip real work (LLM/agent/HTTP calls) and feed a fixture:
|
|
52
52
|
|
|
53
53
|
```ts
|
|
54
|
-
import { executeWorkflow,
|
|
54
|
+
import { executeWorkflow, MemoryEventLog } from "@keystrokehq/workflow";
|
|
55
55
|
import workflow from "../signup-pipeline";
|
|
56
56
|
|
|
57
57
|
it("drafts without calling the agent", async () => {
|
|
58
|
-
const
|
|
58
|
+
const eventLog = new MemoryEventLog();
|
|
59
59
|
const runId = "test-run";
|
|
60
60
|
|
|
61
|
-
//
|
|
62
|
-
|
|
61
|
+
// correlation id = `step:<actionKey>#<occurrence>` (occurrence starts at 0),
|
|
62
|
+
// or `step:<stepId>` if the step used `.stepId("...")`.
|
|
63
|
+
await eventLog.append({
|
|
64
|
+
runId,
|
|
65
|
+
type: "step_completed",
|
|
66
|
+
correlationId: "step:research-signup#0",
|
|
67
|
+
data: { brief: "stubbed brief" }, // the action output goes in `data` directly
|
|
68
|
+
});
|
|
63
69
|
|
|
64
70
|
const result = await executeWorkflow(
|
|
65
71
|
workflow,
|
|
66
72
|
{ name: "Ada", email: "ada@acme.com", company: "Acme" },
|
|
67
|
-
{ runId,
|
|
73
|
+
{ runId, eventLog },
|
|
68
74
|
);
|
|
69
75
|
|
|
70
76
|
expect(result.status).toBe("completed");
|
|
@@ -76,9 +82,9 @@ it("drafts without calling the agent", async () => {
|
|
|
76
82
|
|
|
77
83
|
Rules:
|
|
78
84
|
|
|
79
|
-
- Pass a fixed `runId` and the same `
|
|
80
|
-
- The
|
|
81
|
-
-
|
|
85
|
+
- Pass a fixed `runId` and the same `MemoryEventLog` to `executeWorkflow`.
|
|
86
|
+
- The correlation id is `step:<actionKey>#<occurrence>` — `#0` for the first call to that action, `#1` for the second, and so on — unless the step used `.stepId("x")`, in which case it is `step:x`.
|
|
87
|
+
- The action **output** is stored as the event `data` directly (no wrapper). It is re-validated against the action's output schema, so it must be schema-valid.
|
|
82
88
|
|
|
83
89
|
This is the preferred mock: schema-checked, no module-mock hoisting, and it still exercises the real `run` orchestration (branching, loops, output shape) — only the action bodies are stubbed.
|
|
84
90
|
|