Comments on: JAOO - Day 1

by: Tammo Freese

Sun, 22 Oct 2006 13:10:52 +0000

Hello Helmut,

The extra replay() step in EasyMock is there by design, not by requirement.
It would be possible to do implement something like expect(mock).aMethod()
meaning the expect gives back an object which allows the definition of expected method calls for te mock. When I implemented EasyMock 2 last year, I opted against it for two reasons. First, it is harder to read, since the parentheses look misplaced. Second, it is not possible to chain responses, like in expect(mock.aMethod()).andReturn(”avalue”) - and this means that type checking for return values would not work. However, this decision may change in a future version of EasyMock.

by: Helmut Rubasch

Thu, 12 Oct 2006 19:31:53 +0000

I am quite aware of the advantages of using pure language constructs (that the compiler can check and the IDE can autocomplete) in contrast to pure strings (that are of course not checked in any way during compile time) - in fact, this is one of the main reasons why we are using EasyMock in a project.
Still, some things are rather hard to get used to.
EasyMock’s record mechanism is really clever: everything is done at language level, no meta-language (Strings) necessary. Unfortunately this implies, that you need this extra replay step before you can really use the mock. I don’t know how many times I forgot to replay my mocks - still, you usually find out when trying to break your test, and it just won’t break because the mock is still in recording mode (or does mock.verify() even throw an exception if the mock has not been replayed?).
The ArgumentMatchers are also a very interesting way to accomplish their tasks (unfortunately hard to understand at first, too). Still jMock’s Constraints are slightlier more compact to use (no additional static method necessary).
So each, EasyMock and jMock, has some things that it can do a little better or easier than the other. In a perfect world we could take the best from both camps and build some kind of JEasyMock (to be pronounced like CheesyMock), but the two concepts are just too different for this to work. Even worse, the two base concepts of the two mock libs are in fact the reason for the shortcomings they have: with EasyMock it just won’t be possible to simply provide an ArgumentMatcher to the mock’s method call (the compiler would complain), and with jMock you’ll never have some more compile time verification. There is just no other way to do these things in their world.
After talking so much about the “problems” of those two mock libs: it’s still great to have fabulous tools like these. I could not imagine testing without something like this.

by: Tammo Freese

Thu, 12 Oct 2006 10:03:01 +0000

“This of course poses a problem when you refactor your classes, but the key point is that your test will fail if you provide an invalid method name (jMock checks if a method with the provided name really exists). So you will find out if you did anything wrong.”

As the author of EasyMock, I also think this is one of the main points, but for another reason: Your tests *pass* first, then you apply a *refactoring*, and then your tests *fail*. So automated refactoring does not work correctly when using jMock mock objects.

Using method calls to define expectations in EasyMock provides more benefits than refactoring safety: Both autocompletion and generation work.

As an example for autocompletion, consider we have a String stored in the variable login, and an object of type User stored in the variable user. Now we like to check that User mock.someMethod(String) is called with the String stored in login, and we like our mock to return the object stored in the variable person.

jMock:
mock.expects(once()).method(”someMethod”).with( eq(login) ).will(returnValue(person));
EasyMock 2:
expect(mock.someMethod(login)).andReturn(person);

With jMock, autocompletion would not work on someMethod, and the autocompletion for login and person would be cluttered with other completions, as the type is not checked.

With EasyMock, autocompletion would work everywhere, and the autocompletion for login and person would not be cluttered with other completions, as the type is checked, i.e. the autocompletion at ’someMethod(’ would only show strings, and the completion at ‘andReturn(’ would only show user objects.

As an example of code generation, let’s say you specify a call to a method which does not exist yet on the mocked interface:

jMock:
mock.expects(once()).method(”notYetExistingMethod”).with( eq(42) );
EasyMock:
mock.notYetExistingMethod(42);

With jMock, you have to run your tests to see that the method is missing, and then to define it by hand in the interface. With EasyMock, modern IDEs generate the method automatically for you.