Next I tried creating an embedded Vertx instance in my test and sending messages to my component over the real event bus. This is surprisingly easy and worked well.

The embedded API doesn’t allow you to deploy verticles or start busmods as they are intended to run in isolated classloaders. You can use the event bus, though.

For example consider the following component that handles event bus messages and looks up documents using Vert.x’s Mongo DB persistor:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class MyComponent {
    EventBus eventBus

    void read(Message message) {
        eventBus.send('mongo.persistor', [action: 'find-one', matcher: [id: message.body.id]]) { reply ->
            if (reply.body.status == 'ok') {
                if (reply.body.results) message.reply status: 'found', title: reply.body.results[0].title
                else message.reply status: 'not-found'
            } else {
                message.reply status: 'error', message: 'o noes something went wrong'
            }
        }
    }
}

To test this first I initialized the Vert.x instance and registered my component as a handler on the event bus. I’m waiting until Vert.x calls back to indicate that the handler is registered successfully then storing the handler’s id so that I can easily clean it up after the test:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@Shared def vertx = Vertx.newVertx()
def component = new MyComponent(eventBus: vertx.eventBus)
def handlerIds = new Stack()

void setup() {
    registerHandler 'my.component', component.&read
}

private void registerHandler(String address, Closure handler) {
    def readyLatch = new CountDownLatch(1)
    handlerIds << vertx.eventBus.registerHandler(address, handler) {
        readyLatch.countDown()
    }
    assert readyLatch.await(1, SECONDS)
}

void cleanup() {
    while (!handlerIds.empty()) {
        vertx.eventBus.unregisterSimpleHandler handlerIds.pop()
    }
}

Vert.x’s Groovy API uses closures for all handlers on the event bus so I’ve used Groovy’s .& operator to turn the method on my component into a closure.

Then I added a Spock Mock to represent the Mongo DB persistor that my component will send messages to. This also needs to be registered on the event bus:

1
2
3
4
5
6

def persistor = Mock(Handler)

void setup() {
    // ...
    registerHandler 'mongo.persistor', persistor.&handle
}

Finally, a feature method to test what happens when the requested document does not exist in the Mongo DB datastore:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

void 'read calls back with not-found status if there is nothing in the database'() {
    given:
    persistor.handle(_) >> { Message message ->
        message.reply status: 'ok', results: []
    }

    and:
    def reply = new BlockingVariable<Message>()

    when:
    vertx.eventBus.send('my.component', [id: '1234']) {
        reply.set(it)
    }

    then:
    reply.get().body.status == 'not-found'
}

The mock persistor executes its own callback. Realistically I’d want to use a better matcher for the persistor mock there, but I’ve used a wildcard for simplicity in the example. Note that the reply spy is an instance of spock.util.concurrent.BlockingVariable as I need to ensure the assertion blocks until the callback is actually executed.

This is fine for scenarios where I’m validating the component’s interaction with the persistor. For more complex tests for things like data integrity I’m going to need to figure out a way to wire up real collaborators like the Mongo persistor rather than using a mock. If I figure out a neat way of doing so I’ll post again.

For example, a simple REST server that saves some data might make a call like this:

1
2
3
4
5
6
7
8
9
10
11
12

void post(request) {
    def album = [artist: request.params.artist, title: request.params.title]
    eventBus.send('mongodb', [action: 'save', collection: 'albums', document: album]) { reply ->
        if (reply.body.status == 'ok') {
          request.response.statusCode = 200
          request.response.end 'Updated OK'
        } else {
          request.response.statusCode = 500
          request.response.end "Update failed: $reply.body.message"
        }
    }
}

The the Closure passed to eventBus.send will be called once the save action has been completed and depending on the result the correct HTTP status and message will get returned to the client.

In a unit test we might want to use a mock eventBus but we’re not calling a method that returns a value; how do we get the mock to invoke the callback? It’s not a well documented feature but using a Spock mock you can get to the arguments passed to a mocked method using a Closure like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

void 'the server returns HTTP_OK if the save succeeds'() {
    given:
    server.eventBus = Mock(EventBus)

    when: 'the server gets invoked'
    // for this example let's assume the request has been set up
    server.post(request)

    then: 'the save is executed'
    1 * server.eventBus.send(_, _, _) >> { address, params, callback ->
      callback([body: [status: 'ok']])
    }

    and: 'HTTP_OK is returned to the client'
    request.response.statusCode == 200
}

In a real test you’d want to use stricter matching on the mock interaction, but using Spock’s _ wildcard for the final callback parameter is the right thing to do.

What about testing a method that accepts a callback Closure directly? I’ve found that using a mock works fine there too. Imagine we’re writing a test for this method:

1
2
3
4
5
6
7
8

void parse(input, Closure callback) {
    try {
      // do some complex processing
      callback(status: 'ok', result: output)
    } catch (e) {
      callback(status: 'error')
    }
}

It does some work and then invokes a callback. How can we test that the parameters passed to the callback Closure are correct?

1
2
3
4
5
6
7
8
9
10

void 'callback is invoked with parse output'() {
    given:
    def callback = Mock(Closure)

    when:
    parser.parse('my input data', callback)

    then:
    1 * callback.call([status: 'ok', result: 'my expected output'])
}

This works pretty well. The only downside is that if callback is called with the wrong arguments or not called at all you get the same output in your test results:

Too few invocations for:

1 * callback.call([status: 'ok', result: 'my expected output'])   (0 invocations)

For more helpful output you can use a Closure to trap the arguments passed to the callback like this:

1
2
3
4
5

then:
1 * callback.call(_) >> { args ->
  assert args[0].status == 'ok'
  assert args[0].result == 'my expected output'
}

The old method is possibly my favourite Spock feature. It’s a simple thing but really enhances test legibility. It’s also great for wowing developers new to Spock because it looks like black magic at first glance.

Consider a simple test like this:

1
2
3
4
5

when:
myList << 'foo'

then:
myList.size() == 1

This is fine in simple cases, but what happens if myList.size() is in a less predictable state? I’ve used this technique for testing cache usage for instance; making assertions about hit & miss counts and cache size. Those numbers are less predictable as they’ll be affected by other things (concurrency or side-effects of test setup, for example). Hardcoding expected values makes the tests brittle.

We can improve things a little by comparing the value after the when: block with the value before it:

1
2
3
4
5
6
7
8

given:
def oldSize = myList.size()

when:
myList << 'foo'

then:
myList.size() == oldSize + 1

With Spock’s old method there’s an even neater way, though:

1
2
3
4
5

when:
myList << 'foo'

then:
myList.size() == old(myList.size()) + 1

Wait, WTF is going on there? That’s voodoo!

In fact Spock is using an AST transformation to execute the call to old before the when: block. If you step through the spec with the debugger in IntelliJ Idea you’ll see exactly what’s going on. The execution jumps to the line with old before the when: block lines, then visits it again afterwards.

The old method returns the value an arbitrary statement had before the preceding when: block was executed. Because of this old can only be used in a then: block (or any subsequent and: blocks).

There’s no limit to what you can do with old. I’ve used it in Geb specs to do things like this:

1
2
3
4
5
6
7
8
9
10
11
12
13

given:
to CocktailListPage

when:
to NewCocktailPage
cocktail.name = 'Dirty Martini'
cocktail.save.click()

then:
at CocktailListPage

and:
cocktailList.names == old(cocktailList.names) + ['Dirty Martini']

There’s a slight quirk here in that a failed save will cause the URL to change from /controllerName/create to /controllerName/save. Not a particularly huge issue, after all it’s not something a search spider will see and users will be very unlikely to care. One thing I have found problematic though is when rendering a navigation element that highlights an item based on the current action.

Imagine a bit of GSP code like this:

1
2
3
4
5

<nav>
  <g:link action="list" class="${actionName == 'list' ? 'active' : ''}">List Cocktails</g:link>
  <g:link action="create" class="${actionName == 'create' ? 'active' : ''}">Create Cocktail</g:link>
  <g:link action="search" class="${actionName == 'search' ? 'active' : ''}">Search Cocktails</g:link>
</nav>

This creates a navigation element with links to the various controller actions & highlights the current action. However, if we’ve submitted bad data from the create form no navigation element will be highlighted. With scaffolding this is easy to fix by changing the test to actionName in ['create', 'save'] but with custom controllers the relationship between actions might not always be so predictable and the navigation template will need frequent tweaking to stay up to date as the code evolves.

With the Twitter Bootstrap scaffolding example I created recently I used a different pattern in the scaffolded controller template:

1
2
3
4
5
6
7
8
9
10

def create() {
  switch (request.method) {
  case 'GET':
      // render the form
  case 'POST':
      // save the object
      // if successful redirect
      // otherwise re-render the form
  }
}

Effectively I’ve merged the create and save actions. The form posts back to the create action instead of save. This means the URL only changes when we successfully redirect away from creating our object & the create navigation entry stays highlighted if we screw up creating our object.

I’ve done the same with the edit and update actions. Have a look at the full source on GitHub if you’re interested.

It feels like a step closer to a RESTful interface. I’m using the HTTP verbs to determine what to do with requests to the same URL. Full RESTful mapping isn’t possible as forms will only GET or POST not PUT or DELETE. Also using Grails’ RESTful URL mappings would defeat the point as the action name in the GSP would be different.

This is neat enough but a couple of objections occur:

• I don’t particularly like the switch statement, but controller actions should be kept trivial anyway (controllers are for routing requests around, not performing complex logic).
• Unit testing becomes marginally more awkward as we have to set request.method rather than just invoking a different action.
• This is a sledgehammer to crack a nut & only a pedant would care. Yeah, fair enough.

Looking at the markup it seems heavy and overly concerned with presentation. In this example layout links in the top navbar have no less than 4 divs between them and the top of the document. There are a lot of classes everywhere and almost all of them are concerned with presentation rather than semantics; how a div should look rather than what it represents. Classes like row-fluid, span9 even the ubiquitous btn are slightly troubling as they’re bleeding presentation details into the markup.

I get that these are to some extent practical considerations. Restyling all button elements would be disruptive for people who wanted to drop Bootstrap in to an existing site, for example. Maybe I’m being pedantic but I’ve worked on sites with severe div-itis and it makes things difficult both for maintenance and accommodating changes.

I can’t help thinking that this…

1
2
3
4

  </div><!--/span-->
</div><!--/row-->
  </div><!--/span-->
</div><!--/row-->

…is a code smell.

Bootstrap is built with LESS but (by default) compiles it down to CSS before any of your site’s code starts interacting with the Bootstrap framework.

LESS is great for structuring CSS better but I think its strengths go further.

I recently came across The Semantic Grid System which really leverages the power of LESS (or SASS or Stylus if you prefer) . The semantic.gs provides mixins that you use on the components of your pages. It’s a full-blown responsive grid system with not a column-container, row or grid-8 class anywhere in your markup. In fact, looking at the markup you wouldn’t know the content was being laid out on a grid. It’s all handled in your LESS file. Want your services and clients sections laid out as ⅔ width blocks with your about me section as a sidebar? Just declare:

1
2
3
4
5
6
7

section#services, section#clients {
    .column(9);
}

aside#about-me {
    .column(3);
}

Instead of adding a presentational class to elements in the markup you add a mixin to the element in the LESS file.

Wait a minute… Isn’t that dangerously close to the separation of semantics and presentation that the invention of CSS promised us all those years ago?

1
2
3
4
5
6
7

def myTag = { attrs, body ->
  if (!body) {
      // render a default body
  } else {
      // render the supplied tag body
  }
}

It turns out that if the tag did not have a body the argument passed to the Closure is always the same constant, so what you can do is:

1
2
3
4
5
6
7
8
9

import org.codehaus.groovy.grails.web.pages.GroovyPage

def myTag = { attrs, body ->
  if (body.is(GroovyPage.EMPTY_BODY_CLOSURE)) {
      // render a default body
  } else {
      // render the supplied tag body
  }
}

1
2

expect:
applyTemplate('<my:tag/>') == 'the expected output'

However, one thing I found is that it’s quite tricky to wire a dependency in to the taglib instance that’s used by the applyTemplate method.

Let’s imagine that my:tag makes a call to a Grails service for some reason. In the tag’s unit test you’ll need to wire in a mock or real instance of that service.

Although like with the old TagLibUnitTest and TagLibSpec classes your test gets a field called taglib that doesn’t actually appear to be the instance that applyTemplate uses. This fails:

1
2
3
4
5
6
7
8
9

void setup() {
  tagLib.myService = new MyService()
}

void 'a taglib spec'() {
  expect:
  applyTemplate('<my:tag/>') == 'the expected output'
  // blows up with NullPointerException when the tag tries to call the service
}

Grails 2 unit test mixins provide a defineBeans method that allows you to add Spring beans to a mock application context using the BeanBuilder DSL. So, next I tried this:

1
2
3
4
5
6
7
8
9
10
11

void setup() {
  defineBeans {
      myService(MyService)
  }
}

void 'a taglib spec'() {
  expect:
  applyTemplate('<my:tag/>') == 'the expected output'
  // blows up with NullPointerException when the tag tries to call the service
}

After some digging I discovered that you need to use defineBeans in setupSpec rather than setup for the wiring to work (I guess this would mean in @BeforeClass in a JUnit test). So this does work:

1
2
3
4
5
6
7
8
9
10

void setupSpec() {
  defineBeans {
      myService(MyService)
  }
}

void 'a taglib spec'() {
  expect:
  applyTemplate('<my:tag/>') == 'the expected output'
}

All very well so long as you don’t need to inject a specific instance of MyService into the tag. Unfortunately, often you will need to do exactly that so that you can wire in a stub or mock that your test can control. Also, Spock’s mocks can’t be created in setupSpec only in setup or the specification methods.

The test does get an applicationContext variable, but that doesn’t have a method on its API to allow you to register an existing object as a bean. Spring’s MockApplicationContext does, and after some digging I found that there’s an instance of that available as grailsApplication.mainContext. However a bean added there doesn’t get picked up by the tag either:

1
2
3
4
5
6
7
8
9
10
11

def mockService = Mock(MyService)

void setup() {
  grailsApplication.mainContext.registerBean('myService', mockService)
}

void 'a taglib spec'() {
  expect:
  applyTemplate('<my:tag/>') == 'the expected output'
  // still blows up with NullPointerException when the tag tries to call the service
}

Eventually I figured out that instead of registering your mock dependency in the application context you can instead get the correct taglib instance from the application context and then wire its dependencies directly. I use Spock’s mocks almost exclusively for this kind of thing, but the same technique should hold for any other mocking framework. What I ended up doing is this:

1
2
3
4
5
6
7
8
9
10
11

def mockService = Mock(MyService)

void setup() {
  def taglib = applicationContext.getBean(MyTagLib)
  taglib.myService = mockService
}

void 'a taglib spec'() {
  expect:
  applyTemplate('<my:tag/>') == 'the expected output'
}

Hopefully this is something that will get ironed out in a future Grails release but in the meantime hopefully this will be helpful for anyone who gets as stumped as I did.

I think the crux of the issue is that functional tests, end-to-end tests, acceptance tests, whatever you want to call them are not the same thing as unit tests. They’re not really even just a higher level of the same thing. Yet on the projects I’ve worked on we’ve generally carried on as though they were.

Unit tests are associated almost on a one-to-one basis with units of code. When you execute grails create-controller Foo the framework generates a skeleton controller and a unit test for it. You certainly shouldn’t be slavishly beholden to the one unit test class per production class habit but it’s generally reasonable. Each unit test describes the behaviour of a single unit of the software. I don’t think the same association is appropriate for functional tests but we often end up using it anyway.

I’ve tried to distil some rules of thumb from all this.

1: Organize tests around features not units of code

When it comes to writing functional tests in Java or Groovy the tendency is to follow the pattern of associating tests to some kind of unit of software. Typically it’s a test per web page or significant page component (e.g. ArticlePageSpec, NewsTickerSpec). When dealing with the content management side of apps rather than the public facing it often defaults to a test per high level domain object.

When work is started on new functionality the temptation is often to augment existing tests rather than creating new ones. Oh, this card deals with article pages on the site so let’s go find the ArticlePageSpec and add our coverage there.

The functional tests are supposed to be, among other things, the living, executable documentation for your product. So there should be a strong association between the tests and the features that have been implemented over the life of the project. In the teams I’ve worked on features have been tracked using index cards on a board but the same could apply to issue tracking systems. When using Spock there’s even a dedicated annotation for tying a feature method or specification class to an issue:

1
2
3
4

import spock.lang.*

@Issue("https://github.com/robfletcher/betamax/issues/34")
class HttpsProxySpec extends Specification {

2: Name tests according to features

I think part of the reason the habit of associating tests with units of code is hard to break is naming. Test classes have to be called something and that something is limited by Java’s class naming requirements and conventions. Naming things is often treated as an afterthought, but it’s actually hard. When I start working on a card with a description something like “A user can save articles to a list of ‘favourites’” what am I going to call the functional test class? I should probably go for UserSavesArticleToFavouritesSpec but if this is the first card played that’s to do with favourites maybe I’ll just be lazy and call it FavouritesSpec. Next week someone else plays a card “Users can remove articles from their list of favourites” and adds their coverage to my original FavouritesSpec which is now some hybrid beast testing two different bits of behaviour.

3: Put tests somewhere you can find them later

Over time something I’ve noticed is that it becomes difficult to identify where exactly a certain bit of functionality is covered in the functional tests. Team members fixing defects will sometimes try to figure out who implemented something in the first place and ask them where the tests are or even end up trawling through the Git log. This shouldn’t be necessary.

A corollary to that is that it also becomes difficult to identify redundancy or obsolescence in the functional tests. If a feature of the application is removed or replaced then obviously the tests around it should also be removed. The wrong way to do that is by running everything and deleting whatever fails.

I’ve also seen test cruft floating around (still ‘passing’ somehow) from long-dead features. In some cases so long-dead that we’ve had to go rooting through the code because we can’t remember whether the functionality still exists.

Redundancy is a huge problem on some projects. One in particular had a vast suite of Selenese tests that often repeatedly exercised bits of functionality often nothing to do with what the test was concerned with actually testing. For example the CMS used the Grails URL convention of /type/action/id (e.g. /article/edit/1234). Because such URLs are unpredictable tests would do things like invoke a data fixture then use the CMS’s search tool to find the thing the fixture created and navigate to its edit page.

4: Keep tests atomic

There’s a best practice that states each test should make a single logical assertion and I’d extend that to say that test classes should test a single feature (including variations and edge cases). If the new test you’re writing is nothing to do with the other tests in the class or is only related to them because it deals with some of the same parts of the application then it should be broken out into a new class.

Sometimes this comes at the cost of repeated initialization or data setup and developers’ natural DRY instincts resist that. But in the long run well organized tests will pay dividends over pristine DRY-ness especially as the requirements of individual tests have a habit of mutating over time so that what is common now may not stay that way.

Selenese tests seem particularly prone to run-on testing where what are in reality multiple tests are combined into one because it is easy for the resulting state of an earlier part of the test to feed into further assertions. For example a test that creates an article then makes sure the user can search for it, then uses the search result to navigate to an edit page where it makes sure the article can be updated and finally deleted. A TDD anti-pattern known as “The One”. Spock’s @Stepwise annotation can be similarly abused.

5: Isolate data fixtures for each test

Starting out with simple tests that create some data we’ll often spot some commonality & move some of the data setup into setup or setupSpec methods (@Before or @BeforeClass in JUnit). When successive cards are played and developers augment that test they’ll find the original data is insufficient or inappropriate. Before long there’s a test with some data created in setup, individual tests adding more, some tests ignoring the data from setup completely and worse, some tests actually modifying or even deleting bits of it.

This is not a recipe for a maintainable test. The problems compound themselves. It may not be obvious that one of the tests methods doesn’t actually need the data provided by the setup method so it gets left there as the test evolves. Eventually it can reach a point where the test has changed so much that virtually none of the individual tests actually need the data provided by the setup method or all of them make significant changes to it but it’s still sitting there anyway because that fact isn’t apparent without a very close reading of the code.

I’m not saying don’t write tests that share data created in setup. But do it sparingly and don’t then add tests that don’t need that data; put them somewhere else.

I do prefer tests that set up their own data rather than relying on a common fixture. I think it makes the test read better: the fixture becomes part of the test’s preconditions (the given in the BDD given, when, then structure). That’s not to say that tests can’t share fixtures. Factory methods, fixture loaders and so on are appropriate ways of doing that.

Grails has a couple of plugins that are very useful here; Fixtures and Build Test Data. I’m actually pretty bad at using the Fixtures plugin effectively but am convinced it’s a good idea. Build Test Data is usually among the first plugins I install in any project and it’s very useful for hiding irrelevant fixture detail from the test code.

TL;DR version

I firmly believe that small is good when it comes to functional tests. I want lots of tests each covering some well defined facet of the application’s behaviour, preferably traceable in some way to the original card. I think if I’ve understood anything of Behaviour Driven Development it’s that tests should be organized around product features and not units of code.

Still TL;DR version

I should probably start using Cucumber.

Although it took a little while I found the upgrade less painful than some previous versions. It feels like Grails is really maturing so there are fewer fundamental breaking changes and more in the way of new features. The bulk of the changes we had to make were to unit tests which are vastly improved in Grails 2. That said, I can see some of the things we ran into stumping people so I thought a write-up would make a useful reference. Some of these items may already be covered by the upgrading section of the Grails user guide but some, particularly around plugins are probably new.

Compilation

Firstly we needed to do to just get the build working to the point where tests would run.

Upgrade Spock

Version 0.6-SNAPSHOT of the Spock plugin is required for compatibility with Groovy 1.8.

This also required us to update @Unroll annotations to use Closure parameters. Instead of

1

@Unroll("#a plus #b should equal #x")

the annotation needs to be

1

@Unroll({"$a plus $b should equal $x"})

Whilst this is a bit of a chore there are some advantages to this format as you can reference properties and call methods on the parameters right in the annotation.

Before the tests would run we got a compilation error:

The return type of java.lang.Object mockDomain(java.lang.Class) in com.sky.cms.AssetSpec is incompatible with void mockDomain(java.lang.Class) in grails.plugin.spock.UnitSpec`

There’s some kind of clash between the method signatures of mockDomain in Spock’s UnitSpec and Grails core. We’d intended to switch to the new annotation-based unit test support anyway but apparently we needed to do so right away. On the surface this just meant making our specs extend Specification instead of UnitSpec and introducing the new @TestFor annotation. The other changes we had to make to get our tests running successfully are covered below.

Configuration changes

Configuration-wise all we had to do was to change DataSource.groovy to reference H2 rather than hsqldb. Because we were just dealing with the CMS plugin and its test harness we hadn’t modified the default file in any way so we just replaced it with the new one from Grails 2 with:

1

cp $GRAILS_HOME/src/grails/grails-app/conf/DataSource.groovy grails-app/conf/

Unit tests

The bulk of the time we spent upgrading was spent on unit tests. This is understandable since Grails 2 has made some significant enhancements in unit test support. Most of the changes are pretty straightforward but there are a couple of gotchas here.

• The mockConfig method was always a bit awkward (as anyone who has tried to assign the path to a File object to a config key on a Windows machine will attest) and has been removed. Unit tests now get a genuine GrailsApplication instance injected by default if using one of the new annotations and you can directly assign values to the config property.
• Remove mockDomain calls & add a @TestFor or @Mock annotation to the test class. Use @TestFor(MyDomainClass) for the domain class’ own tests and @Mock(MyDomainClass) when the domain class is a collaborator. @Mock accepts multiple classes if you need it.
• We had a number of assertions about domain validation errors that we had to change from domainInstance.errors.<fieldName> to domainInstance.errors.getFieldError('<fieldName>').code. The latter is more long winded but has the advantage of using the same API as when you deal with Spring Errors instances in application code.
• Tests for a controller that has an allowedMethods declaration must set the request.method or they get a 405: Method Not Allowed response.
• Domain class validation is evaluated on mock domain instances. Often this isn’t actually desirable. Tests cluttered with data setup that is only required to satisfy domain constraints are harder to maintain. To get round this you can use .save(validate: false).
• Domain class event handlers such as beforeInsert are not triggered unless the session is flushed. In the few tests this affected we just had to change .save() to .save(flush: true).
• Assigned ids are wiped from domain object instances when @Mock is used. It seems like even when assigning ids on construction with code like new Pirate(id: 1234, name: "Edward Teach") the id will be null until the save method is called. This wasn’t a big deal for us & mostly meant getting rid of a few magic numbers from test code.
• grailsApplication is not wired into domain instances like it is into controllers and tag libs when using @TestFor.
• We ran into some issues with tests for property editors where we were setting up mock a request variable. We had a NullPointerException thrown from domain class constructors after doing so. Using the request property provided by @TestMixin(ControllerUnitTestMixin) instead fixed things.
• We converted our old tag lib tests to use @TestFor(TagLibClass) and the new applyTemplate method. See the relevant section of the Grails user guide for more details on this.
• Tag libs using @TestFor can actually find and render GSP templates when they call render. This means you might get more realistic output than your test was previously expecting!
• We found that when testing tag libs with @TestFor that modifying the metaclass of the taglib field of the test class didn’t affect tests using applyTemplate. However, we just had to change from taglib.metaClass.blah to MyTagLib.metaClass.blah.

Plugins

Joda Time

We upgraded the Joda-Time plugin to version 1.3. This also meant we had to add the Hibernate persistence library to the dependencies section of BuildConfig as documented here.

Resources

The Resources plugin currently (up to at least version 1.1.1) has a bug that means it does not generate resources properly in anything other than dev mode. There is a workaround; just add the following to BootStrap:

1
2
3
4
5

def grailsResourceProcessor

def init = {
    grailsResourceProcessor.updateDependencyOrder()
}

Geb

We upgraded Geb to version 0.6.1 and the Selenium drivers to version 2.13.0. The only issues we ran into were:

• An additional dependency is required to handle select elements properly (installation details are handily included in the report for any test that fails due to this).
• Setting values on input type="file" elements no longer worked. I’ve already fixed this issue and it should be in the next Geb release. See GEB-152 for more information.

Other Libraries

We had one test that used GMock. Unfortunately it is not currently compatible with Groovy 1.8. For us this wasn’t a big deal as we could easily drop GMock but some codebases may be more invested in it.

Actual Grails bugs

We only found a couple of problems with Grails itself both of which I’ve raised on the Grails bug tracker:

• GRAILS-8376 Constraints on superclass associations are not inherited properly in mock domain instances. This bit us when instances of a child class of a superclass that had an association with nullable: true failed to save. The workaround is to simply duplicate the constraint in the child class (yes, it’s ugly).
• GRAILS-8377 grails test run-app fails with Error loading plugin manager: GebGrailsPlugin. This is kind of an edge case. We were only trying to run the application in test mode to help figure out the problem with resource processing mentioned above.