I have a case where, from a test fixture, I would like to inspect the AR that is created (still using 2.4.6). For example:
`
fixture.givenNoPriorActivity().when(createARCmd).expectEvents(event1, event2);
// somehow obtain the MyAR instance that is created from the fixture
`
Reason i am asking is that the AR is holding on to a few other objects that i would like to inspect the state of. I have encountered a few cases where, in spite of the correct events being thrown, the internal AR business state was not correctly updated.
strictly speaking, this means that you have a test case missing that has the thrown events from this test case and a given().
You might be able to use the fixture’s repository to get hold of the aggregate. This feature hasn’t been implemented, but there may be a way to get round it.
Thanks Allard, not sure i understand your first comment. Imagine this imaginary case:
`
@CommandHandler
public void on(AddItemToInvoice cmd) {
// assume an invoice can have max 10 items
if (this.invoice.checkNumberOfItems() <= 10) {
apply(new ItemAddedToInvoice(cmd.getItemId());
}
}
@EventSourcingHandler
public void handle(ItemAddedToInvoice event) {
this.invoice.addItem(new Item(…));
}
`
… but the Invoice.checkNumberOfItems() method has an off by 1 bug which makes it return (actual number of items + 1).
Anyway i’ll have a look at plugging a the repository in the fixture. Thanks for your insight.
Wouldn’t a better way to handle that case be to have an explicit test for the “invoice can have max 10 items” rule? After the tenth item, you’d expect an AddItemToInvoice command to produce no events, but it’ll produce an unexpected ItemAddedToInvoice.
I realize that’s just a made-up example, but we’ve had really good success treating the AR as a black box that accepts a series of events and a command and returns events. All possible AR bugs will either manifest in the form of a thrown exception or an incorrect event being output at some point. It is actually the major thing that makes writing tests in Axon such a pleasant experience in my opinion.
Yes in this case sending 10 cmds would detect the problem, but my case was a bit more complex as well. Anyway looking at my business case again, I admit that not properly verifying all business conditions in the commandhandler caused the bug I was hoping to detect by accessing the AR from the fixture. After fixing up the commandhandler I can detect the invalid state easily just by looking at the emitted events. Indeed it makes sense to treat it as a black box in that way.