Continuum.Runtime.ActivityStubs (continuum v0.8.1)

Copy Markdown View Source

Activity stubs for in-memory test runs.

The user-facing surface is the :activities option on Continuum.Test.start_synchronous/3; this module validates it and resolves a stub at the point the in-memory journal would otherwise invoke the real activity body.

Stubs live in the Continuum.Runtime.Context, not in a registry keyed on the calling process: the workflow body runs inside the Engine GenServer, not in the test process, so anything stored in the test process is invisible where it is needed.

A stub cannot influence a command_id. Command identity is computed at macro expansion from the call site and assigned before the effect is dispatched, so a stubbed run journals byte-identical command identity to a real one — which is what makes a stubbed unit test's history meaningful.

Summary

Functions

Resolve a stub for an activity call, if one is registered.

Produce a stub's value for one call.

Validate and normalize the :activities option.

Types

key()

(since 0.8.0)
@type key() :: {module(), atom()} | {module(), atom(), arity()}

t()

(since 0.8.0)
@type t() :: %{optional(key()) => term()}

Functions

fetch(stubs, module, function, args)

(since 0.8.0)
@spec fetch(t(), module(), atom(), list()) :: {:ok, term()} | :error

Resolve a stub for an activity call, if one is registered.

A more specific {module, function, arity} key wins over {module, function}.

invoke!(stub, args)

(since 0.8.0)
@spec invoke!(term(), list()) :: term()

Produce a stub's value for one call.

A function of the activity's arity is invoked with the activity's arguments; any other value is returned as-is. The result is validated the way the Postgres adapter validates a real activity result — in-memory writes skip DurableTerm.validate!, so without this a stub returning a PID would pass the unit test and be rejected in production.

validate!(stubs, arg2)

(since 0.8.0)
@spec validate!(term(), module()) :: t()

Validate and normalize the :activities option.

Refuses stubs on the Postgres journal: a durable activity runs in an activity worker process, out of a claimed task row, with retry, timeout, and idempotency semantics of its own. A stub cannot reach that path, and silently ignoring one would make a "passing" durable test meaningless.