Unit testing event handler behaviour

[Marcus Linke]

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

[Allard Buijze]

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

--
You received this message because you are subscribed to the Google Groups "Axon Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Marcus Linke]

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

[Allard Buijze]

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

[Marcus Linke]

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

[Allard Buijze]

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

[Marcus Linke]

Hi Allard,

big thanks for enlighten me with your detailed explanation!

Best regards

Marcus