I am using GivenWhenThenTestFixture with AbstractAnnotatedAggregateRoot successfully for most cases.
One Aggregate changes per one Command (one Transaction) - I am following DDD principles.
But…
There are some cases, when to handle one Command, I need two Aggregates to act with eachother.
Consider following example:
One Aggregate (A1) is being changed (produces events).
Another (A2) is used as a Factory for some Policies that are used as closures to A1 method (and based on that, A1 generates some additional Events). But A2’s state is not being changed!
In Command Handler, there are two Repositories - one for A1 and another for A2.
Now I want to test that Command.
What I can do now is to setup a fixture for A1, and inject a mocked repository for A2 with an instance of A2 prepared manually (by invoking methods on object).
This may be ok, but involves using mocks in domain test (which I don’t consider as a good practice), or using read side (which is even worse, since invariants should be in the model on the write side, because it is consistent).
It also mixes given-when-then approach based on events with manual Aggregate manipulation.
What I would like to have is to specify “given” events for A1 and “given” events for A2, and then send my Command as “when” and then as “then” specify expected events for A1 and expect A2 not to change at all.
Something similar to fixture for sagas.
It seems to me that, in this case, A2 isn’t really dealing with commands. It’s used as a factory/repository. So either you’re executing a query (and should use the query model), or you can model (at least that part of activity in) A2 as a Domain Service (see ddd for definitions).
Axon’s fixtures are really meant to test a single aggregate. If you need other behavior, you can always resort to regular unit tests.
You are right - A2 isn’t dealing with commands (as far as we both understand “dealing” in the same way. ) - it is acting as Factory of Policies.
I don’t want to ask read side - I want to use my model.
I understand how fixtures are made. This is a great piece of work.
Just from the DDD point of view, there is nothing bad in my case (still changing only one Aggregate’s state) and it would be nice to be able to test it in similar fashion as other valid cases with given-when-then.
So it looks like I have to manually create the instance A2, mock the repository and inject that mock into Command Handler.
I can live with that for some time…
Do you have any plans to extend the fixture to handle cases similar to this one?
I currently don’t have any plans for supporting more than one aggregate in the test fixtures. The way it’s currently made possible (by injecting a mock) seems like a good enough solution for the case.
) - it is acting as Factory of Policies.