A comparison between easymock and jmock 1/2 would be a good point for future articles from my point of view. I like the simplicity of jmock 1 and easymock, but decided to use jmock 2 at work instead. Though, it might all be personal reference.
Nice introduction. I'll print it out and put it into our office tomorrow.
I think Andy is correct. The re-ordering of your expectations is much clearer. I also think the re-ordering is really important for clarity and maintainability I have a few more examples at my blog: http://zdsbs.blogspot.com/2009/01/easymock-vs-mockito.html. But it seems to me Mockito's syntax makes it a better choice for mocking than EasyMock or jMock. But that's just my 2 cents.
First, we (obviously) prefer JMock. The structure is a little arcane but we wrote it that way to make the relationships between the object under test and its neighbours as clear as declarative as possible. JMock is "opinionated", it's designed to push the code in the "right" direction.
EasyMock tends to bury this information in a list of method calls and I find that when working with EasyMock I have to put a lot of effort into making the tests expressive, and interpreting failures can be challenging. I also keep forgetting to call replayMocks().
Mockito, on the other hand, is an interesting challenge to us. It's very easy to use, which makes it a good introduction, but it's forgiving approach means that it doesn't push the design of the code as hard as I like. Talking to the author, it turned out that his initial motivation was to cope with the unpleasantnesses in the code base he was working with. We prefer to improve the code (and the skills of the team).
A comparison between easymock and jmock 1/2 would be a good point for future articles from my point of view. I like the simplicity of jmock 1 and easymock, but decided to use jmock 2 at work instead. Though, it might all be personal reference.
ReplyDeleteNice introduction. I'll print it out and put it into our office tomorrow.
Markus, glad you enjoyed it. It's a lot for one page... hard to do much beyond raising awareness or wet the appetite.
ReplyDeletePersonally, I also prefer jMock style mocking.
-Dave
You should also take a look at Mockito.
ReplyDeletehttp://code.google.com/p/mockito/wiki/MockitoVSEasyMock
It removes the need to specify your expectations before running the test and so appears in a more sensible order
// Create the mock
MyClass myClass = mock(MyClass.class);
// Do something with the mock
result = doSomethingWith(myClass);
// Verify that the mock was called correctly
verify(mock).myMethod("Testing"); // The string comes from the doSomethingWith...
+1 for Andy
ReplyDeleteAfter having used JMock, EasyMock and Mockito my favorite Java mocking framework is Mockito: http://mockito.org/
I think Andy is correct. The re-ordering of your expectations is much clearer. I also think the re-ordering is really important for clarity and maintainability I have a few more examples at my blog: http://zdsbs.blogspot.com/2009/01/easymock-vs-mockito.html. But it seems to me Mockito's syntax makes it a better choice for mocking than EasyMock or jMock. But that's just my 2 cents.
ReplyDeleteRe: "See the EasyMock documentation at the link below for details"
ReplyDeleteThere was no link below.
(Disclaimer. I'm an author of JMock)
ReplyDeleteFirst, we (obviously) prefer JMock. The structure is a little arcane but we wrote it that way to make the relationships between the object under test and its neighbours as clear as declarative as possible. JMock is "opinionated", it's designed to push the code in the "right" direction.
EasyMock tends to bury this information in a list of method calls and I find that when working with EasyMock I have to put a lot of effort into making the tests expressive, and interpreting failures can be challenging. I also keep forgetting to call replayMocks().
Mockito, on the other hand, is an interesting challenge to us. It's very easy to use, which makes it a good introduction, but it's forgiving approach means that it doesn't push the design of the code as hard as I like. Talking to the author, it turned out that his initial motivation was to cope with the unpleasantnesses in the code base he was working with. We prefer to improve the code (and the skills of the team).