Unit Testing with Mocks – EasyMock, JMock and Mockito

The oxford dictionary defines mock as – “make a replica or imitation of something”. That very much holds true in the case mock assisted unit testing.

My definition…“Mocking is the discipline of identifying the dependencies of the unit being tested and thereafter providing imitations of that dependency, such that the class being tested has no knowledge whether the dependency is real or an imitation.”.

There is a distinction on what you really expect to test in a unit test – State verification vs Behavior verification. I would point you to an excellent article by Martin Fowler regarding the same – http://martinfowler.com/articles/mocksArentStubs.html

In the real world the difference between the two blur and sometimes for a good reason. You do not have all the time in the world to sit down and write the ideal set of unit tests for each. State verification typically checks to see if the state of objects is as expected after the tests have run. Behavior verification is about checking to see if certain methods were invoked (and how many times, and what arguments were passed ,etc).

Using Mock frameworks you can stub out what data you want returned from a call to a dependent class. And that is what is of interest to me. Imagine a service class calling a classic data access class. I want to test the service class but stub out the calls to the DAO. At the same time I want the DAO to return different sets of data so as to exercise my different paths in the service class.

In the Java sphere there exists a few strong frameworks to help the
developer in mocking dependencies. In this blog I will
cover examples of three frameworks – EasyMock, JMock and Mockito.

The frameworks typically provide the following features:

  • Mock both classes and interfaces (you cannot mock final methods or final classes).
  • Return your own data from calls to mock objects.
  • Allows you to mock an exception from the mock object.
  • Chain multiple mock calls.
  • Specify how many times a method must be called in a unit test.
  • EasyMock and Mockito support partial mocking.

Lets look at real examples. As usual the complete Eclipse project is zipped up and available at the very bottom.

EasyMock follows the following design paradigm:

  • Create the Mock
  • Connect the mock with the object being unit tested
  • Set up the expectation on the mock (which methods on the mock need to get invoked, how many times, etc). To set up the expectations you call methods on the mock and thats it. The mock object will record the facts so as to verify it later.
  • Replay mode. Hereafter the mock will keep track of invocations to itself and throw exceptions if
  • Execute the test
  • Verify the mock invocations.

In this test case I have not recorded any expectations. By default EasyMock mocks will then expect that no invocations can be made to it. This test case will fail with an error (entire stack trace not included)

Now lets look at a happy path examples where an expectation is provided.

This test case will pass since we have recorded one expectation and the test execution did invoke the expected method, which was verified in the call to verify.

Now lets try to stub out the data that is returned from our DAO object.

Variable vazips holds some hardcoded stub data. We would like that a call to dao.getZipCodes with an argument of statecode=VA return us this test data. The way we do this is in expectation

To throw an exception from our DAO use:

As you can quickly see there is some amount of value to mocking out dependencies. What you have to guard is an over-dependence on mocking. I have seen test cases that set up so many expectations that after a while it is hard to understand what they were really testing. If you only do behavior verification then I personally think you have not unit tested the code. In the end of the day everything is about business logic and data. Your unit tests should verify those. As in the last example we have used EasyMock to return some test data so that we can unit test different execution paths in our service.

JMock is very similar in that you set up expectations, then execute and finally verify.

If you had to throw exceptions from your mock then


Mockito is a relatively new framework. Where it differs from EasyMock and JMock is in the way it deals with expectations. In the case of EasyMock and JMock you have to record the expectations. Mockito does not do require you to do that. It lets you verify mock invocation verifications (of your choosing) AFTER the test is executed.

In this case you connect your class to the mock object as before, then simply run your test. After the test is executed you verify that expected methods were called. In this case a call to getZipCodes with an argument of “VA”. Change the argument to “CA” and the verification will fail.

Here is how you would stub data.

Finally if you were to mock exceptions..

Each has its own advantages but none so ground breaking that one rules over the other. Use what you are comfortable with.

Click here to download the zip containing the source code and eclipse project. Please download libraries from: http://www.easymock.org , http://www.jmock.org , http://www.mockito.org