jmock versus easymock (a trivial example), 11/10/05, Colin's blog

October 11, 2005

jmock versus easymock (a trivial example)

So I decided to have a look at easymock.

It looks very nice. Some of the main benefits include:

direct method calls, so refactoring works
less overhead required because you are manipulating your objects, not mocks

For example, there is an object call RequestScopeModelAccessor which stores/retrieves things under FlowScope within a web flow.

Using jmock, the get method can be tested:


    public void testGet() {
        String key = "key";
        Object obj = "object";

        // set up for writing
        Scope requestScope = new Scope(ScopeType.REQUEST);
        requestScope.setAttribute(key, obj);
        Mock context = mock(RequestContext.class);
        context.expects(atLeastOnce()).method("getRequestScope").will(returnValue(requestScope));

        RequestScopeModelAccessor accessor = new RequestScopeModelAccessor(key);
        assertEquals("get", obj, accessor.get((RequestContext) context.proxy()));
    }

whereas with easymock:


    public void testGet() {
        String key = "key";
        Object obj = "object";

        // set up for writing
        Scope requestScope = new Scope(ScopeType.REQUEST);
        requestScope.setAttribute(key, obj);

        RequestContext requestContext = createMock(RequestContext.class);
        requestContext.getRequestScope();
        expectLastCall().andReturn(requestScope);
        replay(requestContext);

        RequestScopeModelAccessor accessor = new RequestScopeModelAccessor(key);
        assertEquals("get", obj, accessor.get(requestContext));
    }

As you can see, the code is much easier to read, and the mock framework is much less intrusive with easymock.

This of course is a very simplistic example, but it has encouraged me to look a bit deeper :)

BTW: I am using prerelease 2.0 which will only work with jdk 5.

: 11 Oct 2005 10:29 | Tags: Easymock Jmock Test Unit | Comments (9) | Report a problem

9 comments by 2 or more people

[Skip to the latest comment]

Chris May

       context.expects(atLeastOnce()).method("getRequestScope").will(returnValue(requestScope));

method-naming genius :-)

11 Oct 2005, 10:56

we can but try :). Actually Keith Donald can but try as that's his method ;)

11 Oct 2005, 11:19
Chris May

I'm not sure I'd agree that easyMock code is easier to read, though. A quick scan through both methods suggest that the first one tests 2 things:
- accessor.get() returns obj
- in doing so, getRequestScope is called once and returns requestScope
In the second version, the assert is as obvious as before, but WTF is going on with that replay() business ? and expectLastCall() is a bit wierd and side-effecty if it does what I think it does. Great care needed when modifying test cases.

Of course, that's not to say that it's not a good framework – it may well be much nicer to write tests with. But to an untutored eye, it doesn't seem so readable. Plus, if Keith Donald wrote JMock then it gets 10 bonus points right there for being related to Spring :-)

11 Oct 2005, 11:41
The point about easyMock being easier to read is that you are manipulating your objects, using your API, but you are right, there is still a fair amount of EasyMock overhead.

The replay method is basically saying, "ok, I know what to do, let me at them". expectLastCall is a way of indicating the return value.

Don't think Keith wrote jmock, but he did write the "getRequestScope" method. Did I miss the point of your last entry? :)

11 Oct 2005, 11:54
Chris May

Did I miss the point of your last entry?

Maybe; my point was how nicely that line as a whole reads. Just take out some of the punctuation and add a few prepositions, and you get

'context' expects (at least once) that method "getRequestContext" will return the value 'reqestScope'.

(Using 'something' to mean "the object called something")

Which is amazingly readable. Fiddle around with the semantics of the first method parameter and you get

'context' expects that method "getRequestContext" will return the value 'reqestScope' at least once.

which is about as clear a statement of an expectation as you're ever likely to see.

11 Oct 2005, 12:26
Thats actually a really good point. Maybe I have been looking at the matrix for too long :)

11 Oct 2005, 13:01
Tammo Freese

Instead of

requestContext.getRequestScope();
expectLastCall().andReturn(requestScope);

you may write

expect(requestContext.getRequestScope()).andReturn(requestScope);

This works for all methods that have a non-void return value.

24 Oct 2005, 16:38
cool. Thanks Tammo.

24 Oct 2005, 21:43
Chris May

{hurries off to eclipse to implement Tammo's suggestion…}

:-)

01 Nov 2005, 20:14

Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

Trackbacks

Trackback URL: http://blogs.warwick.ac.uk/colinyates/entry/jmock_versus_easymock/trackback/

October 11, 2005