Sequence-driven CMD (aggregate) test spec — Layer A (pure).

Inject a sequence of commands into an aggregate and, after EACH command, assert the four things that matter for a command-side domain:

1. the aggregate emitted the EXPECTED events,
2. the aggregate emitted NO UNEXPECTED events,
3. the aggregate did NOT fail (unless the step expects an error),
4. the aggregate is in the CORRECT state.

(1)+(2) are a single check: the emitted event-type list is compared EXACTLY (in order) to the expected list, so an extra event is a mismatch — "no unexpected events" comes for free.

This layer is PURE: it drives Mod:init/1, Mod:execute/2 and Mod:apply/2 directly with no event store, no processes. State threads through the sequence by folding each command's emitted events via apply/2, so command N runs against the state left by commands 1..N-1 — true sequence semantics. This mirrors exactly what the runtime does: evoq_aggregate calls Module:execute(AggState, Command#evoq_command.payload) then folds events with Module:apply/2. We pass the command type to the handler the same way the dispatch path does — as command_type inside the payload map.

Two equivalent forms

Tuple-list (table-drivable):

  evoq_aggregate_spec:run(vehicle_aggregate, <<"veh-...">>, [
    {commission_vehicle, #{vehicle_id => Id, ...},
         expect([<<"vehicle_commissioned">>]),
         fun(S) -> vehicle_state:is_commissioned(S) end},
    {pick_up_passenger, #{vehicle_id => Id},
         expect_error(vehicle_not_dispatched),
         unchanged()}
  ]).

Builder (readable for long scenarios — thread the spec):

  S0 = evoq_aggregate_spec:new(vehicle_aggregate, Id),
  S1 = evoq_aggregate_spec:emits(
         evoq_aggregate_spec:exec(S0, commission_vehicle, #{...}),
         [<<"vehicle_commissioned">>]),
  S2 = evoq_aggregate_spec:state(S1, fun vehicle_state:is_commissioned/1),
  ok = evoq_aggregate_spec:done(S2).

Both raise erlang:error/1 on the first failed assertion, so they slot straight into eunit/common_test.

NOTE: the persistence half (does the command actually persist through evoq_dispatcher against a real store, with a valid stream id?) is Layer B — see evoq_cmd_case. The four pure assertions here CANNOT catch a persistence/stream-id bug.