Comments on: Returning Parameters in JMock 2

By: Adrian Sutton

Adrian Sutton — Wed, 05 Jan 2011 14:53:43 +0000

Nice. Not sure why I didn’t notice the TypeSafeMatcher class when I was originally doing this.

By: IndividualRich

IndividualRich — Wed, 05 Jan 2011 14:49:29 +0000

I like your solution but I’m not a fan of catching the ClassCastException. Here’s a revision using TypeSafeMatcher that gets rid of the try-catch;

class CapturingMatcher extends TypeSafeMatcher implements Action {

public T captured;

public void describeTo(Description description) {
description.appendText(“captured value “);
description.appendValue(captured);
}

public Object invoke(Invocation invocation) throws Throwable {
return captured;
}

@Override
public boolean matchesSafely(T arg) {
captured = (T)arg;
return true;
}

}

By: Adrian Sutton

Adrian Sutton — Wed, 10 Mar 2010 11:07:06 +0000

I suppose you could assert that it’s passing in a specific default value just as easily and then you’d know what to return, but that defines more about the implementation than I think a test really should (at least in this case). I probably would have just done that if I didn’t already have the capturing matcher around to make my life easier with complex asserts. In this case the mock is half stub/half mock so I want to be as loose as possible in what method calls and arguments are used (mostly) and just assert that the result is correct.

By: Steve Freeman

Steve Freeman — Wed, 10 Mar 2010 11:00:19 +0000

Thanks for posting the tip. describeTo() is intended to help you understand what has happened when it goes wrong.
I’m curious, though, as to why this trick is necessary in a unit test. Surely you know what the expected default value should be?

By: Adrian Sutton

Adrian Sutton — Wed, 10 Mar 2010 09:47:44 +0000

Yeah I’ve seen Mockito, there’s not really enough that’s better to justify rewriting everything. JMock 2 has a very friendly syntax, with the only weird bit being the context.checking wrapper. I think the JMock API is actually much easier to read than Mockito in many ways, mostly because it uses full words (equal instead of eq) and better matching normal lingo – e.g. will(returnValue(…)) instead of thenAnswer since Java returns things it doesn’t answer.

It’s all much a muchness though.

By: Nathan

Nathan — Wed, 10 Mar 2010 03:32:58 +0000

Slightly off topic, but from this post note that you’re using Jmock for mocking framework. Have you ever looked at Mockito? http://code.google.com/p/mockito/

I’ve found it’s much more intuitive than other mocking frameworks. Supports hamcrest as well, so with similar CapturingMatcher def as you’ve got (implementing Answer instead of Action), you would end up having something like:

when(mockObject.getParameter(eq(“expectedParameterName”), argThat(returnCapturedValue )).thenAnswer(returnCapturedValue);