Parameterized specs with Jasmine

Spock’s where block makes testing similar conditions for a bunch of inputs very straightforward. Recently I was working on the Groovy language definition for the Prism syntax highlighter and wanted something similar.

I used Jasmine to test-drive my code and wanted to be able to make some very similar assertions about how the highlighting operated. For example, a particular code block should contain particular characters highlighted as operator tokens. The assertions for each of Groovy’s (many) operator types would look extremely similar with the only variance being the id of the code block and the expected operator tokens. Using Spock this would be a classic case for writing a single specification method and applying a where block.

Using SASS and Compass with Gradle

I recently started helping with the Ratpack website. It is (or will be) a Ratpack app & built with Gradle. I started prototyping with a simple webapp created with Yeoman and using SASS and Compass for authoring CSS. When I migrated the work-in-progress into the ratpack-site application I initially used Ted Naleid’s method of calling Yeoman’s Grunt tasks from Gradle. Unfortunately this meant there were rather a lot of build dependencies. In order to build the app you would need Node.js, Ruby and the Compass gem installed. Peter Ledbrook pointed out this could frustrate potential contributors & Marcin Erdmann proved an example of what he meant. Clearly I needed to simplify.

Grails and REST URL mappings

When building a REST-style API with Grails there’s a very handy way of configuring URL mappings. For example:

"/person/$id?"(resource: "person")

will map requests to /myApp/person to the different actions of PersonController according to the HTTP request method. The mappings are GET->show, PUT->save, POST->update, DELETE->delete.

Mongo dynamic attributes and Grails unit tests

When using Mongo DB with GORM it’s possible to assign to dynamic attributes of a domain class. However, you’ll find that when you write unit tests for code that uses this feature it isn’t supported. It’s easy to emulate, though.

Groovy gotchas: overloading the assignment operator

When assigning to a property of an object in Groovy using the assignment operator = Groovy will look for a bean property style setter method. For example x.foo = y is equivalent to x.setFoo(y). Or is it?

Groovy gotcha: for loops and closure scope

You probably know that Groovy closures retain information about the scope in which they were created. The closure body can refer to values that were in scope where the closure was declared. There is a gotcha here that has bitten me a few times, though. That’s when closures are created in a for loop.

Stateful interactions in Spock

The Java mocking library jMock has a nice feature for dealing with verifying mock interactions in stateful circumstances. I first came across it when reading Growing Object-Oriented Software Guided By Tests (GOOS) by Steve Freeman & Nat Pryce.

I was curious as to whether I could implement something similar with Spock. There’s no syntactic support right now (although there is an open issue) but it’s not that complex to achieve something adequate.

Grails builds on Travis CI

Travis CI is a cloud based continuous integration service. It’s a great way to automate test runs for projects hosted on GitHub. Since the Grails wrapper was added to Grails in version 2.1 you can use Travis to build Grails apps.

Dropwizard

First brought to my attention by Kris Lander I was initially a bit doubtful about Dropwizard. It seemed heavy on ceremony & perhaps a little too opinionated when it comes to deployment.

We’ve tried it out and been pretty impressed, though. It has a great set of features for developing REST APIs. It’s fast to start, lightweight and uses annotations rather than stringly-typed conventions to tie your code to the framework. Monitoring – which is often an afterthought – is central to the platform in Dropwizard.

You’re not stuck with Java and Maven either – Groovy and Gradle is a viable option.

I’d like to do some more experimentation with unit testing Dropwizard apps as there are a few hoops to jump through currently.

It’s generating some buzz at the moment. To get you started here’s a set of slides from a talk given last week by Kyle Boon at the Groovy Users of Minnesota.

Groovy & the public keyword

One of the first things you learn in Groovy is that unlike Java public is the default scope for properties and methods declared on classes. Most developers get into the habit of simply omitting the public keyword everywhere. But, is there any situation where it’s the right thing to use? Actually, yes.