In this post, I show how we can keep method names in spock data tables to make testing easier.
Inspired by Rob Fletcher’s talk on Spock at the London GGUG, we continued trekking into the unknown worlds of Spock.

Very often, we write convenience methods within our services. For example, we might have a createFirePokemon() method, which uses the same call as a createWaterPokemon() method under the hood. Another example might be createAdminUser() and createRegularUser().
By using invokemethod ( line 22 ), we can provide a test that allows us to quickly run through the different permutations for a factory method. This allows us to keep method name as another parameter in the data table.
When things go wrong, the unroll annotation ( line 16 ) will show the failing test as create pokemon FIRE with method firePokemon() or create pokemon WATER with method waterPokemon(), depending on which row has failed.
Continue reading →