Is anyone testing using the Spock Framework and Groovy?
I’m building a system based on Axon and I use Spock for all my tests.
The BDD-like API for testing your Axon components is awesome for Java, but I’m using Groovy so I would prefer to write my tests in a more groovier way (more expressive, easier to read, etc) rather than the Java-way (using the fluent API). Especially when Spock already have Given/When/Then right in the DSL.
Is this possible? Any recommendations on how to use the fixtures (and it’s configuration/components) in a non-fluent way?
Has anyone solved this or have any experience from using this approach?
Nothing wrong with the readability on the fluent API. It’s great when writing your tests in Java.
But lately we’ve been trying to move away from Java/JUnit for testing, and are using Spock and Groovy exclusively, just because the tests are faster to write and easier to read.
So the Java-way might feel a little… old age like you said
So, it’s the fixture configuration complex? I’m thinking (if it’s not too complex) that I’ll give it a shot and try to make Groovy-based fixture. And maybe use/extend Spock to take advantage of the DSL blocks given/when/then…
the fixture configuration is pretty easy. Probably, the simplest way for you to approach this, is to create an adapter for spock that uses the Axon fixture underneath.
I have to admit that this style of testing is a lot cleaner. I’m not that old, really. Looking forward to seeing how you pull it off. Ping me if you need any help.
Cheers,
You can use either events or commands. From the Reference Guide:
“Alternatively, you may also provide commands as “given” scenario. In that case, the events generated by those commands will be used to event source the Aggregate when executing the actual command under test. Use the “givenCommands(…)” method to provide Command objects.”
Yes, like I just told Allard (did the mistake to reply only to him and not in the group - new to google groups :)) :
Right now I’m working on the Restful API for our new project. As soon as we start creating the tests for our new Axon command handlers I will give it a try.
So, I finally got some time to play with this. This is what I came up with, it’s a DSL that uses the default Axon test fixture classes in the background. You can define your command and events in a static or dynamic way. Note: Due to language limitations in Groovy and current limitations in the Spock Framework I was not able to create the DSL I really wanted. But for Groovy, Spock and Gradle users I think this DSL is very natural and still simple.
Statically: You define the commands and events in your test by using pre-built instances, just like when you use Axon’s fluent API. Since it’s static you get constructor parameters help (autocomplete/intellisense) from your IDE. The downside is that the command/event definition is not that expressive and you have to use the ’new’ keyword.
Dynamically: This way you don’t need to create instances (no need for the ’new’ keyword). You define your commands by specifying the command/event class and payload separately. The payload is the arguments that will be used to construct an instance, so the arguments must match the class constructor. Arguments can either be named or ordered. This is much more expressive, however, the downside is that you won’t get any context help (constructor parameter help) for your commands/events.
this looks really nice. I’m thinking on how to best include this in the Axon project (assuming that that’s what you’d like to do with it).
What I’m wondering is how much any change in the API of the test fixtures (e.g. a new method) would impact the Groovy API.
I’m currently creating/converting a TodoBackend example - http://www.todobackend.com - using Axon/SparkJava/Spock and that DSL example that you created looks great!
Did you even get around to putting that DSL code into a GitHub project or the like?
