Monthly Archives: August 2010

Geb and Grails – tips, tricks and gotchas

I’ve been getting familiar with Spock and Geb for the last few weeks. Here are some quick notes, links and files that I have compiled from this experience. I’ve gathered them here for my own quick reference.

Geb is Luke Daley’s fantastic new functional testing library based on web driver. To get started with it, you need to read the book of Geb. Continue reading

My Groovy / Grails / Flex / Testing Reading List for August

Here are a few books that I am currently reading / found interesting / want to read in my work with Groovy, Grails and learning more about test driven development. In no particular order,

Groovy in Action, 2nd Edition (MEAP)
Covers new interesting topics like GPars and updates the original version based on the new features in Groovy.

The Book of Geb
This is Luke Daley’s online manual for the newly developed Geb functional testing library. Geb contains a lot of really neat features such as jQuery-like selectors, web driver support and page object patterns. Definitively a must read for Grails / Groovy enthusiasts.

Growing Object-Oriented Software, Guided by Tests
Saw this book on Rob Fletcher’s twitter stream and am really learning a lot from it. It is a bit of a dense read, but contains very interesting ideas about how to approach testing from the outside in.
Continue reading

Fun With Spock & Grails – Method invocations in data tables

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