This test executes the event handler method which was unexpected for me.
Hi Sam,
To be honest, I don’t see any issue with the given/when/then Test Fixture architecture to encounter issue with going over every Event Sourcing Handler.
The idea of the given is to recreate your state.
If your using the Event Sourcing approach for this, the most sensible approach is to actually calling your Event Sourcing Handlers to recreate it.
Additionally, the purpose of the Test Fixtures set up is to define your business logic through given events, handling a specific command and expecting a certain event output from that.
How that’s dealt with internally by the Aggregate, thus what state is adjusted or which (event/command handling) methods are called with that, only diverts from what should be tested.
Lastly, for the second question you posted in this thread regarding the Aggregate Identifier between the dispatched command and the expected events.
The check is not performed on the when/then step, but between the given and when steps.
It’s this stage being in charge of this as the ‘given’, if specified, will be the place where the aggregate-creation-event resides.
Thus, that’s the event which will set the Aggregate Identifier for that specific instance you’re testing.
If you would check the aggregate identifiers between the given-events and when-command, you should receive the following exception:
java.lang.AssertionError: The aggregate used in this fixture was initialized with an identifier different than the one used to load it. Loaded [aggregate-id], but actual identifier is [other-aggregate-id].
Performing this assertion on the expected-events really is part of how you dispatch events form the Aggregate your testing.
If you decide to dispatch events with other state in it regarding the aggregate identifier, that’s all your choice.
Hope this sheds some light on the situation Sam.
Cheers,
Steven