Mockito preferrable over easymock?

Question

Hi there,

recently I made the switch to Mockito framework and am very happy with it (see also blog-post). The switch from easymock to Mockito was very straightforward and I managed to make the tests down compatible (i.e. test cases behave the same).

Do you see real reasons or shootout criteria to prefer easymock over Mockito? So far of the codebase I worked with I can't, but am interested in your point of view.

Answer 1

I'm more familiar with EasyMock than Mockito, so I had to do a little digging. Mockito has a page that does an explicit comparison from the Mockito point of view.

As I see it, the advantages of Mockito are:

• Explicit separation of stub and verification
• Matchers are based on Hamcrest (also supported by JUnit) instead of a custom API
• Created mocks are always 'nice'; that is, method calls that are unmocked return clean data (like an empty list) instead of failing

EasyMock has a very similar function set. The core differentiators for Mockito are based on those areas of EasyMock that the Mockito team thought were limitations or sub-optimal practices.

From a functional point of view, neither product is able to mock static methods (I needed to do this for testing without an MBeanServer), but in that case you can use PowerMock on top of either framework.

I'd say go with whichever style fits your testing requirements.

Hope this helps!

Answer 2

Mockito may be better now than it was when I last tried it, but it lost me when it changed its API to be incompatible with previous versions. Upgrading to the latest version would have required me to change many of my existing unit tests, which I found unacceptable. I decided it was too immature and unstable for my needs.

That doesn't mean that there's anything wrong with it, though. The version I was using still works fine, although I've since switched back to EasyMock.

Answer 3

Mockito was developed to allow BDD-style unit testing, that is:

• Given (the context in which your unit-test runs)
• When (the events producing the behaviour you're interested in)
• Then (the outcome you're looking for).

as opposed to

• Given
• Expect (here's where the verification gets done)
• When
• Then (go back and look at what you wrote in the Expect because there's no actual info here).

IMHO it produces more readable tests, and allows you to separate things like the context in which you're running (setting up the Mocks) and verification of the behaviour you're interested in. Previous mocking frameworks required you to set up expectations for every interaction, regardless of whether it was relevant to the aspect of behaviour you were looking at in that test or not.