Axon comes with a great fixture test tool that provides a fluent, bdd styled (given/when/then) API to write aggregate and saga tests. So far, so great.
JGiven on the other hand provides a great java based test tool for junit/junit5 that supports strict type safe separation of the different Arrange/Action/Assert Stages and also great reports that can be used to document features.
Knowing these two tools, I came up with “axon-jgiven” … writing axon tests the jgiven way (written in kotlin and primarily addresses kotlin, but should also be usable with java). This is how a test of the giftcard example looks like using axon-jgiven:
Hi Jan,
So: what do you think?
I think it is super awesome you’re sharing such a tool you’ve been working on with the rest of the community!
Thus I highly applaud your effort and hope others can benefit from your work too.
Keep us posted if new, interesting stuff occurs with this project you’re working on! 
Cheers,
Steven
Would love to see property driven testing with axon. I’ve seen some people talking they have it implemented for the axon to produce randomized payloads of data, im guessing nothing public.
Seeing what you did there on the bdd, i do not think that the checking state is that important for aggregates, mostly they are black boxes which just publish certain events, this is why property based testing would be perfect addition for axon.
Good luck with your thing 
I’m not sure though why people are doing test frameworks, everything you posted i can do with plain JUnit.
Well, state of aggregate testing was not the goal here … the main benefit is to combine the fluent axon-test api with the power of jgiven. All methods that are provided by the axon-test fixture are also supported by my lib, you might want to check out the test sources on github for more examples.
Of course all of this could be done with plain junit, but I like how jgiven helps to write reusable steps that are clearly separated into given/when/then scopes - and the advanced readability and reporting it gives me … so basically this lib is “syntactic sugar”. But I like it that way, maybe someone else will like it too.
The property based approach would in deed be interesting.
Thanks for your thoughts
Jan
