Java Mock Objects: EasyMock vs JMock

I prefer EasyMock 2.3 to JMock 2 for working with Mock Objects in Java. It used to be the other way around.

The main reason is that EasyMock has support for Partial Mocking, which JMock lacks. In most other respects they are now approximately similar.

This is the technique of mocking individual methods of a real class, while leaving other methods with their normal implementation. This enables you to test interactions between methods of the same object. Once you get the hang of this technique, you discover it is extremely powerful, and it is hard to imagine mocking without it.

An EasyMock Gotcha

When EasyMock fails because you call a method too many times, the fail message can be confusing; something like…

java.lang.AssertionError:
Unexpected method call doProgrammedTurn():
doProgrammedTurn(): expected: 1, actual: 1 (+1)

…means that doProgrammedTurn() was called twice. It fails as soon as the expected count is exceeded, so presumably the bracketed value is always +1.

Update: PowerMock, a better EasyMock?

PowerMock is an EasyMock-derived tool that adds the ability to mock static, private, and final method invocations via bytecode manipulation at class load time. Im looking at switching over to it.

7 Comments

  1. Jones said,

    March 19, 2008 at 11:51 pm

    If you worry about the interactions between methods of the same object then either your design is too complicated and the object needs to be divided up, or you don’t understand what mock objects are for.

  2. benhutchison said,

    March 20, 2008 at 12:35 am

    Its common to hear comments like Jones from sceptics of Partial Mocking.

    Their argument is based on the belief that an “object needs to be divided up” if you find yourself needing to use (and test) private methods, because this means the class is getting to complex. I find this reasoning unconvincing.

    Dividing an object up is a much more expensive operation than Extracting a Method. So you should only do it when its benefits your system.

    Partial mocking enables you to maintain effective unit testing when Extract Method is your chosen step to perhaps factor some duplication or break up a complex method into parts.

  3. Ricard Mayerhofer said,

    June 26, 2008 at 3:17 am

    That’s because you are probaly violating the single responsibility principle.
    It makes no sense to test interaction between methods in the same class.

  4. Timothy Reaves said,

    August 30, 2008 at 6:13 am

    Partial mocking has nothing to do with “violating the single responsibility principle” (for whatever definition of that you care to contrive) or not understanding mocking: If a method under test is supposed to call a second method in that same class (that tears down expensive resources on an exception for example) then it is fully reasonable to mock that class so that the expensive method is NOT executed, while the method being tested can assert that is was called.

    That’s what testing is about folks. And Google’s gmock supports that. Too bad jMock does not.

  5. Roger said,

    January 21, 2009 at 9:07 am

    Thanks that probably explains why I got the same weird message “expect: 1 got :1”

  6. Pavel Grushetzky said,

    January 8, 2010 at 8:57 am

    I was working with JMock for a while, and partial mocking is really what I miss there.
    I don’t buy claims that partial mocking is somehow bad, or is the indication of bad design. I never heard how method calling another method is bad design, or why this interaction should not be tested.

    Example above with factored out logic is a good one. Suppose A() calls B(). A() has 4 logic branches, B() has 3. Lets count how many tests we need here.

    With partial mocking we need 3 tests for B(), and 4 tests for A() that include A()->B() interaction validation. 7 tests altogether. Extra logic branch for A() costs 1 test. Extra logic branch for B() costs 1 test too.

    Now, without partial mocking we need to test all possible combinations of logic branches for A() and B(). That is, 3×4=12 tests. Extra logic branch for A() costs 3 tests. Extra logic branch for B() costs 4 tests. Happy maintaining.

    To give more practical example at hand, look e.g. at java.io.Reader class. How would you test those read() variations with partial mocking? Without it?

  7. April 26, 2013 at 7:00 am

    Generally I don’t read article on blogs, however I wish to say that this write-up very compelled me to check out and do so! Your writing taste has been surprised me. Thanks, very great article.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: