Revised example test with added assertions to verify methods are being called. Thanks to Nat and Geert Baeyaert for spotting this.

Up until recently (a few hours ago, that is…), I lived with the notion that Mock Objects are a necessary evil. You don’t exactly like them, but you can’t really do without them. They have obvious advantages, but something about them never felt quite right.

So I spent my little recent while attempting to figure out the most likely among a number of potential candidates for the Mock Object API of my liking in Groovy, and, believe you me, there are plenty of options. The answer – with the help from a bunch of nice people on the Groovy dev mailing list:

No Mocks.

The technique does not have to be Groovy specific, I’m pretty sure it can be achieved with most non-statically typed languages that support closures and the ability to dynamically attach behavior (methods) to Objects.

Groovy’ s (relatively) secret weapon for the task is the Expando class. Oversimplified, instances of Expando are expandable Objects to which you can add methods in the form of closures.

Here’s an example of my mock-less unit test:

package aerie.response

class ForwardResponderTest extends GroovyTestCase {

  void testShouldForwardResponse() {

    def getRequestDispatcherCalled = false
    def forwardCalled = false

    def dispatcher = new Expando()
    def request = new Expando()
    def response = new Object()

    request.getRequestDispatcher = { location ->
      assert "/location" == location
      getRequestDispatcherCalled = true
      dispatcher
    }

    dispatcher.forward = { req, resp ->
      assert request == req
      assert response == resp
      forwardCalled = true
    }

    new ForwardResponder(request, response, "/location").respond()

    assert getRequestDispatcherCalled
    assert forwardCalled
  }
}

… for the following class:

package aerie.response

class ForwardResponder implements Responder {

  def request
  def response
  def location

  def ForwardResponder(request, response, location) {
    this.request = request
    this.response = response
    this.location = location
  }

  def respond() {
    request.getRequestDispatcher(location).forward(request, response)
  }
}

It’s worth noting that here we’re dealing with testing contents of the javax.servlet API, one of the most notorious in terms of its un-testability packages in Java.

For starters, if we considered the test in question in traditional Mock Object terms, we’d find ourselves in a situation where we’d have to write a Mock for HttpServletRequest on which we would expect a call to getRequestDispatcher(String location), which would in turn return another Mock – RequestDispatcher, on which we’d expect forward(HttpServletRequest request, HttpServletResponse response) to be called. In “I like my code compact and concise and the intent of my tests clear” terms: insane.

What Expando does for us here is Stubs with an attitude. Done right.
This test is all down to language level – assert is a Java keyword. We’re nowhere near importing a Mock library or having to understand the mechanics of a paradigm that is not native to the core language. We are asserting on what and only what we want to be asserting on. The class under test is tested completely in isolation and there is zero clutter in the form of stubbed interface implementations of the shunt collaborators that interact with it.

Of course none of these would be possible if the language, or design concerns, disallow or discourage duck typing. But even if we’re worried about whatever problems might arise from the lack of statically typed parameters or strongly typed objects, I would suggest that the absence of it is quite OK and manageable at package level where everything is under our control and outsiders cannot really go too creative – as in dangerous – with it.

This entry was posted on Thursday, December 7th, 2006 at 10:59 pm and is filed under Software. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.