good afternoon, I’m running the events sourcing tests, but they only find @CommandHandler that is in the builder:
Error:
Aggregate:
Test:
if I change any CommandHandler to the “command” stay in the constructor it starts to work, it’s like I couldn’t find the “handle” methods
Hi Renanh,
I noticed a few things in your code samples.
You are missing the empty instance of the aggregate. Also, the first @CommandHandler is placed above the PatientAggregate.
Would you try this and let me know if you still have errors showing?
@Aggregate(snapshotTriggerDefinition...)
public class Patient {
@AggregateIdentifier
private UUID id;
Patient() {
}
@CommandHandler
public void handle(UpdatePatientCommand cmd) {...}
}
How to speak all tests work when the commands are in the constructor.
Also using the application normally, all events are correctly persisted, my problem is only in Axon Test, that the commands only work when it’s in the constructor and I don’t understand why.
Let me give my two cents to the situation.
Only the Aggregate creation test works, as that’s the only place where the test’s “given” is set correctly.
The FixtureConfiguration#givenNoPriorActivity as only used whenever a new Aggregate is instantiated. That’s what no prior activity is aimed at.
All your other command handlers, so from the snippet the Update and Delete command handlers, do have a given event to source the aggregate for testing.
Hence for those tests, you should use FixtureConfiguration#given(Objects... events).
You should fill that method’s events parameter with the events you expect to have occurred on the aggregate before handling that command.
As a side note, I’d like to point out that CUD-like commands and events are typically not recommended. The beauty of this message-driven application style is that your commands and events can express the exact adjustments in your application. Things like “patient visited doctor” or “patient address changed.”
Using messages of that format clearly shows to you and your business what’s happening in your app.
Thanks Steven, it worked, now I understand how this flow of life works.
I perfectly understand the reason for using this technology, using CUD-like does not really apply to this use, but it is just something for concept, if an application is only CUD-like, it is very simple to use an architecture like this. But as I’m studying Axon just so I can later include it in my clients, I used it but I’ll change it.
Thank you very much, you are always excellent. I’m a big fan of your work.
I perfectly understand the reason for using this technology, using CUD-like does not really apply to this use, but it is just something for concept, if an application is only CUD-like, it is very simple to use an architecture like this. But as I’m studying Axon just so I can later include it in my clients, I used it but I’ll change it.
Cool, that’s great to hear Renanh! Just wanted to make sure that point was shared, as it would be a shame you’d find this out some years down the line.
Thank you very much, you are always excellent. I’m a big fan of your work.
Much appreciated again Renanh! Everybody at AxonIQ is very happy to help out whenever we can with any of our products. Looking forward to chat with you again in the future!
