Hi,
i just wonder how to unit test event handler logic in axon. There is no possibility to get the aggregate root object from the test fixture for some reason. Could someone explain that please?
Thanks
Why do you want to get the aggregate from the fixture?
Aggregates expose behavior, so in your unit test, you want to make sure they behave as expected. You do that, by specifying past events and an activity (i.e. command). Then, you make sure the aggregate takes the correct decision.
If you really need the aggregate itself, you could try using the Fixture.getRepository() and loading it from there.
Cheers,
Allard
Hi Allard,
thanks for fast response first. Fast as always… 
Maybe its a fundamental misunderstanding of mine but how could i check that the event handler manipulates the aggregate’s state in the expected manner otherwise?
Testing that some command will apply some specified event(s) is good but not good enough i think. Bugs in the aggregate’s event handling are hard to find due to the use of a separate read/view model.
In my own scenario the wrong aggregate state may cause errors really late after applying a lot of other commands.
However, using Fixture.getRepository() works for me but needs to have a running UoW. This could/should be handled by the fixture
itself somehow in my opinion. So it would be great to have an opportunity to pass the expected aggregate into the fixture that compares it by equals() or at least get the aggregate from it directly. What do you think?
Cheers
Marcus
Hi Marcus,
it’s rather a religious issue. On the command side, state is just maintained to support behavior. The fixture is built to help you validate that behavior. That’s why it doesn’t expose (or validate) the state of your aggregate directly. What if you refactor to make an aggregate perform better? That would change state and fail a test case, while the aggregate in fact still works fine.
Just imagine the aggregate state is wrong, but all behavior is correct. Would that be considered a bug? (Food for thought… if you can’t observe it as a bug, it doesn’t exist)
If you really, really, want to test the state of your aggregate (which I recommend you not to do), you could instantiate and initialize the aggregate yourself. Simply call initializeState(…) with an EventStream. Then, check the state of your aggregate. The fixture exposes the event store from which you can fetch events.
Cheers,
Allard
Hi Allard,
thanks for clearing this up. Hmmm, so maybe i really have to rethink some aspects of my application. One question: Consider someone (maybe me ;)) needs to pass some of the aggregates data to an external system while processing a command. Should he/she pull the data from the read/view model in favor from the aggregate directly? Using the aggregate as datasource seems a bit more “natural” to me. In this scenario correct aggregate state is essential and needs to be tested. But maybe i’m totally wrong with all of this…
Thanks
Marcus
Hi Marcus,
the basic rule is simple: the aggregates on the command side never provide state information. If you want to know something, the query side is the only place to go. So if you need to pass data to an external component, you use “a” query model for that. Ideally, that query model is owned and maintained by the component responsible for the external communication.
This design ensures god decoupling between systems. Once you use your aggregate to respond to queries, you have a unwanted dependency.
[commercial content]
This is pretty hard to grasp. That’s why, in my training, I spend a good amount of time on this topic:
http://www.trifork.nl/en/home/training/axon-immersion.html
But once you get the hang of it, the nasty feeling about it will go away, and your components will benefit from much better decoupling.
[/commercial content]
Hope this helps.
Cheers,
Allard
Hi Allard,
big thanks for enlighten me with your detailed explanation!
Best regards
Marcus