The Disco Blog

From time to time, I’ve found that mocking various dependencies can be helpful in testing behavior. Briefly, mocking an object allows you to fake its behavior so as to more fully isolate some other object depending on this behavior — the classic use case is that of mocking a data access layer, for example. In this case, testing some object that depends on a DAO object becomes a bit easier if you can mock out the DAO and thus not have to worry about an associated database, etc.

There are a plethora of mocking libraries out there (and in many cases, you can roll your own!) — one of my favorites for a long time has been EasyMock. This library has served its purpose for me when I’ve needed it; however, there’s a newer library on the block dubbed Mockito, whose hip description is best read word for word:

Mockito is a mocking framework that tastes really good. It lets you write beautiful tests with clean & simple API. Mockito doesn’t give you hangover because the tests are very readable and they produce clean verification errors.

Indeed, Mockito can mock classes just as easily as interfaces and in many ways, I’ve found its API to be much more natural and BDD-istic. Watch.

Each library is similar in spirit — for instance, when providing a stubbed implementation of a hip object, you request a mock of it and then you instruct the various frameworks on how to behave. For instance, with EasyMock, if you’d like to mock an instance of a Feed class (don’t worry too much about this class, suffice it to say, it is used in a ScoreBoard class, which is the class under test), you can do it like so:

scenario "using easy mock", {
  given "a mocked instance of feed", {
    feed = createMock(Feed.class)
    expect(feed.allScores()).andReturn( [new FootballGame(
        "Cleveland Browns", 20, "San Diego Chargers", 3)] as FootballGame[]
    )

    replay(feed);

  }
  then "things should work normally", {
    scoreBoard = new ScoreBoard(feed,
            new FootballGame("Washington Redskins", 0, "New York Giants", 45));

    games = scoreBoard.getAllScores()

    games[0].awayTeamScore().shouldBe 3
  }
}

As you can see in the EasyMock example (which is being driven via easyb), the Feed class’s allScores method is stubbed — in this case, a fake score is created (rather than say, retrieved from a live scoring system located on another server, for instance). Note how with EasyMock, the fluent interface-like API reads expect and return. With EasyMock, things get started via the replay method — as you can see, later in the scenario, this behavior is validated, thus demonstrating the mock.

EasyMock is definitely easy; however, watch the same example play out with Mockito:

scenario "using mockito", {
  given "a mocked instance of feed", {
    feed2 = mock(Feed.class)
    when(feed2.allScores()).thenReturn([new FootballGame(
       "Cleveland Browns", 20, "San Diego Chargers", 3)] as FootballGame[]
    )
  }
  then "things should work normally", {
    scoreBoard = new ScoreBoard(feed2,
            new FootballGame("Washington Redskins", 0, "New York Giants", 45));

    games = scoreBoard.getAllScores()

    games[0].awayTeamScore().shouldBe 3
  }
}

On the surface, things look to be the same, however, if it’s your bag and you look closely, you’ll see that Mockito’s API reads nicer: when then return — this is quite BDD-like, no? Plus, Mockito doesn’t require a replay-like call. Thus, to me, Mockito is a bit cleaner — it certainly complements easyb stories and scenarios with its when and thenReturn API calls.

While I’m only scratching the surface of features available in both libraries, Mockito’s API is more in tuned with my way of thinking — can you dig it, man?