Unit Testing Controllers With The Testing Plugin

Grails JUnit tests are, as you are no doubt aware, divided into unit tests and integration tests. Unit tests run fast, aren't dependent on the database or Spring context but mean you have to live without all the dynamic magic that Grails attaches to your artefacts (controllers, taglibs, domain classes, etc.) This can certainly lead to some sub-optimal test code.

Lets consider an example. I want to write some test coverage for a controller that looks up a domain object based on a parameter and places it in the model. Usual disclaimer: of course, in the real world I'd have written the test first, etc. Nothing much to the controller:

class LolrusController {
   def show = {
       def myLolrus = Lolrus.findByName(params.lolrusName)
       render(view: 'lolrus', model: [lolrus: myLolrus])
   }
}

and here's the domain class:

class Lolrus {
   String name
   String mood
   static hasMany = [posessions: Item]
   static constraints = {
       name(unique: true)
       posessions(validator: { posessions ->
           return posessions.any { it.type == 'bukkit' }
       })
   }
   String toString() { "Lolrus[$name]" }
   boolean equals(Object o) { return o instanceof Lolrus && o.name == name }
   int hashCode() { return 37 * name.hashCode() }
}

Okay, so a reasonable test (ignoring edge cases for now) could be to create a couple of domain objects, make a request to the controller and verify that the correct domain object is retrieved. Simple, right?:

class LolrusControllerTests extends GroovyTestCase {
   def controller
   def lolrus1, lolrus2

   void setUp() {
       controller = new LolrusController()

       lolrus1 = new Lolrus(name: 'Hugh')
       lolrus2 = new Lolrus(name: 'Alan')
       [lolrus1, lolrus2]*.save(flush: true)
   }

   void testShowActionFindsCorrectLolrusAndSticksItInModel() {
       controller.params.lolrusName = lolrus1.name
       def model = controller.show()
       assertEquals('/lolrus/show', controller.modelAndView.viewName)
       assertEquals(lolrus1, controller.modelAndView.model.lolrus)
   }
}

Unfortunately, not so simple. The test fails and reports

expected:<Lolrus[Hugh]> but was:<null>

What we've forgotten of course is that Lolrus has a mandatory field mood and a custom validation on its posessions association that requires it to have a bukkit. The two Lolrus instances we tried to create in setUp couldn't be saved. Great. Well, let's just add that to the test set up:

    void setUp() {
       controller = new LolrusController()

       lolrus1 = new Lolrus(name: 'Hugh', mood: 'worryingly cheerful')
       lolrus1.addToPosessions new Item(type: 'bukkit')

       lolrus2 = new Lolrus(name: 'Alan', mood: 'mildly distressed')
       lolrus2.addToPosessions new Item(type: 'bukkit')

       [lolrus1, lolrus2].each {
           assert it.save(flush: true), it.errors
       }
   }

Okay, it works but look how much of what's going on in setUp is actually nothing to do with anything the test cares about. This is a very simple example with a single test case. Imagine how much worse that setUp method is going to get when we add more tests or the Lolrus domain object gets more complex... Imagine the refactoring required when the Lolrus domain object acquires other constraints... Imagine the query is more complex requiring more domain objects to be set up to really prove it works...

Okay, we could mock the Lolrus class, but the code for that isn't much cleaner and alarm bells start ringing when you start using mocks in an integration test. Shouldn't this be a unit test? Sure, that would be nice but we're using the render dynamic method in our controller, we'll have to mock that out on the metaClass, mock out the findByName method on Lolrus, etc. etc. Too much hassle right? Not any more.

grails install-plugin testing

Allows us to (among other things) write controller unit test cases like this:

class LolrusControllerUnitTests extends grails.test.ControllerUnitTestCase {
   def controller
   def lolrus1, lolrus2

   void setUp() {
       super.setUp()
       controller = new LolrusController()

       lolrus1 = new Lolrus(name: 'Hugh')
       lolrus2 = new Lolrus(name: 'Alan')
       mockDomain(Lolrus, [lolrus1, lolrus2])
   }

   void testShowActionFindsCorrectLolrusAndSticksItInModel() {
       controller.params.lolrusName = lolrus1.name
       controller.show()
       assertEquals('show', renderArgs.view)
       assertEquals(lolrus1, renderArgs.model.lolrus)
   }
}

Much neater. We're not worrying about the constraints required to set up valid Lolrus instances, but neither are we having to mock out the findByName method.

The mockDomain method allows you to set up some domain objects for which all the usual Grails domain class dynamic methods will work - including findBy..., addTo..., etc. The collection passed as the second argument to mockDomain defines all the instances that exist and they can be retrieved just as a real domain object could. The mockDomain method co-exists happily with regular Groovy mocks and the testing plugin also provides some lighter mocking capabilities via its own mockFor method.

Additionally the controller's render method and params property work without any work on our part. This is true of all the dynamic properties and methods of the controller, request, response, params, controllerName, redirect, etc.

Not only that, but this test runs faster than the integration test as it's not configuring the Spring container or an in-memory database. That speed difference only grows as the project becomes more complex - it's a couple of seconds between the two tests here, but in a more complex project it's a lot more.

There are a couple of gotchas (the plugin isn't fully mature). First off you need to remember to call super.setUp() in order that all the Grails stuff happens. The ControllerUnitTestCase class will figure out based on the class naming convention which controller class it needs to mock up. Secondly, the domain class get method doesn't seem to work with non-standard identifier types at the moment (i.e. anything other than a Long). However, this unit testing support is intended to get rolled into Grails 1.1 so it should improve rapidly.

This is only part of what the testing plugin can do. Support for unit testing domain class constraints, etc. is also included. I've also been working on a TagLibUnitTestCase that works along the same lines as ControllerUnitTestCase.