The day started out cloudly and with a lot of rain. Fortunately the rain stopped during the day and for the next few days it should stay dry. This makes the walks to and from the hotel more comfortable. After registration there was some sweet pastry and drinks. For me the day started with presenting Getting Groovy, a beginner workshop for working with Groovy. It was nice to see people get there first contact with Groovy through Gradle and Spock on their Java projects. The presentation and notes are available online.
How to Fetch RSS feeds into MongoDB with Groovy
Suppose we will fetch some Amazon AWS news into a MongoDB database. These few lines made it possible with the use of Groovy and the Gmongo module:
Grails Tip: Getting JSON directly from Grails MongoDB-GORM Low Level API
One of the nice things about MongoDB is that documents are returned in JSON format.
If you use the Mongo-GORM plugin, however, the driver conveniently converts the returned results into a Grails domain class instance. You then have to serialize this domain class to get a JSON result back.
Choosing DropWizard to deliver content within your Grails projects
In our current project, we’re using DropWizard alongside Grails. It has become a fairly significant and useful tool for building simple content delivery layers.
Spocklight: Writing Assertions for Arguments Mock Methods
My colleague Arthur Arts has written a blog post Tasty Test Tip: Using ArgumentCaptor for generic collections with Mockito. This inspired me to do the same in Spock. With the ArgumentCaptor in Mockito the parameters of a method call to a mock are captured and can be verified with assertions. In Spock we can also get a hold on the arguments that are passed to method call of a mock and we can write assertions to check the parameters for certain conditions.
Spocklight: Change Return Value of Mocked or Stubbed Service Based On Argument Value
My colleague Albert van Veen wrote a blog post about Using ArgumentMatchers with Mockito. The idea is to let a mocked or stubbed service return a different value based on the argument passed into the service. This is inspired me to write the same sample with Spock.
Grails Goodness: Checking Results from Forward Action in Controller Unit Tests
In Grails we can write unit tests for controllers. We can check for example the results from a redirect() or render() method. To check the result from a forward() action we can use the forwardedUrl property of the mock response object. The format of the URL is very basic and has the following form: /grails/(controller)/(action).dispatch?(queryParameters). So we get the servlet representation of a Grails controller request. We can use this format to check if our forward() method is correct in the unit test.
Grails Goodness: Passing Objects to Attributes of Tags in Unit Tests
Unit testing tag libraries in Grails is easy. We can use the applyTemplate() method to execute a tag and check the output. We pass the HTML string representing the tag to applyTemplate() as we would use it in a GSP. Attribute values of a tag can be String values, but also any other type. To pass other types in our test as attribute values we must add an extra argument to applyTemplate(). The argument is a Map with model values which are used to pass as value to the tag library attributes.
Spocklight: Using a Custom Hamcrest Matcher
In a previous blog post we learned how we can use Hamcrest matchers. We can also create a custom matcher and use it in our Spock specification. Let’s create a custom matcher that will check if elements in a list are part of a range.
Spocklight: Support for Hamcrest Matchers
Spock has support for Hamcrest matchers and adds some extra syntactic sugar. In an expect: block in a Spock specification method we can use the following syntax value Matcher. Let’s create a sample Spock specification and use this syntax with the Hamcrest matcher hasKey: