AnnotatedSagaTestFixture

I’ve been evaluating sagas for future development, and I think there may be an optimization to how failed matches are reported when unit testing. When the AnnotatedSagaTestFixture is used like this:

fixture.givenNoPriorActivity().whenAggregate(uuid).publishes(new EventOne(uuid, “command one”)).expectDispatchedCommandsMatching(payloadsMatching(exactSequenceOf(hasProperty(“message”, equalTo(“Entity two created+”)), andNoMore())));

The following exception will occur if the incorrect message is returned. The “but got” section implies that only a GenericCommandMessage is getting returned when in fact the correct command type was contained within the payload of the GenericCommandMessage and the contents of the payload did not match. It seems like you should be able to override describeMismatch in PayloadsMatcher and return a more useful exception in the case of bad data from the CommandValidator.assertDispatchedMatching(Matcher<?> matcher) method.

Thanks,
Jacob

org.axonframework.test.AxonAssertionError: Incorrect dispatched command. Expected <List with Messages with Payloads matching <list with exact sequence of: <hasProperty(“message”, “Entity two created+”)> (FAILED!) and <>>>, but got <List with org.axonframework.commandhandling.GenericCommandMessage@3aeaafa6>
at org.axonframework.test.saga.CommandValidator.assertDispatchedMatching(CommandValidator.java:119)
at org.axonframework.test.saga.FixtureExecutionResultImpl.expectDispatchedCommandsMatching(FixtureExecutionResultImpl.java:136)
at org.example.axon.test.TheUnitTest.test(TheUnitTest.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

Hi Jacob,

I think you’re absolutely right. I haven’t used describeMismatch before, so I’m gonna have to play around with the wording a bit to find out how the fixture can produce the clearest message.
If you have any tips/hints or code that you can share, that’s most welcome.

Cheers,

Allard