For the last two weeks I’ve worked with EasyMock and coming from a JMock background it’s easy to make a comparison between the two libraries.
I have to say that I’m less than impressed by EasyMock: the whole concept of the two different states (recording and active) for the mock library looks unreasonable.
Let’s look on how we can create a mock with EasyMock:
MyInterface mock =EasyMock.mock(MyInterface.class);
//actual call to the mock
//verification that the method has been called
There’s also a more DSLish style of defining expectations, that I personally prefer (it differentiates clearly the definition of the expectation from the actual method call).
This style is the only one available when the expectation is more complex:
But what if I want to define that a certain method will be called on the stub, no matter how many times ?
I can either use a different way of creating the mock:
or using the DSL way:
I think that having two ways of defining the same expectation is pretty confusing, specially when you’re using the API for the first time. What I’m looking for in a mock library is the capability of defining the expectations in a coincise but expressive way and then inject the dependency in the object I want to test.
JMock2 is pretty close, but I have to admit the the inner class notation with all those curly brackets around is not helping.