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);

        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);

        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.

- 9 comments by 2 or more people Not publicly viewable

[Skip to the latest comment]
  1. Chris May

    method-naming genius :-)

    11 Oct 2005, 10:56

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

    11 Oct 2005, 11:19

  3. 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

  4. 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

  5. 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

  6. Thats actually a really good point. Maybe I have been looking at the matrix for too long :)

    11 Oct 2005, 13:01

  7. Tammo Freese

    Instead of


    you may write


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

    24 Oct 2005, 16:38

  8. cool. Thanks Tammo.

    24 Oct 2005, 21:43

  9. 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.

October 2005

Mo Tu We Th Fr Sa Su
Sep |  Today  | Nov
               1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Search this blog



Most recent comments

  • Interesting… While I'm not completely convinced in such microbenchmarks, I'm pretty sure that 1ms … by Alexander Snaps on this entry
  • Hello. I bought the book yesterday. I was trying to find the source code for chapter 11 and chapter … by Suleman on this entry
  • http://woosight.net/account/login?username=demo by live mashup demo on this entry
  • Thanks mate ….. This blog was really helpful. by Maaz Hurzuk on this entry
  • Ty. Not directly helpful for my problem, but pointed me in the right direction. You will also get th… by Mike E. on this entry

Blog archive

Not signed in
Sign in

Powered by BlogBuilder