Java: EasyMock vs Mokito

[IHateMyJob2004]

Both seem about equal with there own pros and cons. Seems like they are significantly similar in terms of what they can do when configured to do what you want. Most differences are related to the strict and nice behaviors which both projects handle. EasyMock is more powerful but Mokito is sinmpler to use.

EasyMock can handle expected calls better and Mokito can not (not that I'd use this functionlaity) handle this notion. This is referring to the fact that you can test for Foo.bar() being called exactly 4 times. The check for being called exactly 4 times is handled by EasyMock but not Mokito. (unless this has changed with newer version)

And as a side note I am using PowerMock to extend the behaviors that EasyMock and Mokito do not handle. In my case, I need to mock static methods and this requires Powermock.

I just want to hear some of the thoughts by those that have used these projects for unit testing purposes.

 

[Leros]

I previously used EasyMock. It's kinda old and limited, there are better things to use now.

People seem to be gravitating to JMockit and I've been switching to using it myself. So far, I've been able to do everything I want in JMockit including some things I couldn't do in EasyMock.

JMockit has mocking library comparison on their wiki. Not sure how biased it is, but JMockit does have more features than the other libraries I've looked at. https://code.google.com/p/jmockit/wiki/MockingToolkitComparisonMatrix

 

[brianmanahan]

mockito (with powermock added if needed) seems to be the most prevalent java mocking framework now. last 3 places i have worked used mockito most prevalently. other devs i talk to in my area are using it as first choice as well.

and yes, mockito can check for exact number of calls:

verify(mockList, times(3)).add("some string");

and i would say that statics should really be refactored if possible, because they suck for testing. but i have run into cases where it would take way too long to do that, so i used powermock until i could get a chance to refactor.

 

[IHateMyJob2004]

Using a 3rd party API (Siemens NX) that uses static methods. So there is no way around them when mocking.

Statics have a place. There is no reason to refactor them out. Mostly referring to the singleton pattern. I'm not opposed to them with util methods either. We have some custom math that is in static methods. I might refactor them out but it is low priority.

Statics can get scary if you are using multiple threads though. But even then it is not a big problem. We are for the most part not doing that. Only one project is multi-threaded.

Back on topic:
Does JMockit handle the mocking of static methods?

 

[brianmanahan]

Statics have a place. There is no reason to refactor them out. Mostly referring to the singleton pattern.

most times i have seen static methods used, the code would have been better using instances instead. it was usually done because unit testing was not being practiced, and the static method made the method marginally easier to call (no need to create an instance to call it on).

Back on topic:
Does JMockit handle the mocking of static methods?

a quick google search would indicate that yes, it is possible: http://stackoverflow.com/questions/26408253/how-to-mock-a-static-method-from-jmockit

 

[IHateMyJob2004]

Ya, googled JMockit after my post. Saw that it does static methods. Might read up more on it when I get some free time.

I suppose when it comes to things like the built in Math class that I think the static methods are fine. The Math class carries no state so there are no issues with thread safety. It would be strange constantly calling new Math().min(1,2) to do anything.

Probably nitpicking at this point though.

 

[Leros]

Back on topic:
Does JMockit handle the mocking of static methods?

Yeah it does.

The thing that finally made me switch to JMockit is that JMockit allows you to mock base method implementations while not overriding the overriden methods in an extended class.

 

[beginner99]

My personal opinion is if you have to mock a lot your better of just writing an integration test. Then you actually now the components work together.

 

[IHateMyJob2004]

My personal opinion is if you have to mock a lot your better of just writing an integration test. Then you actually now the components work together.

Unit tests and if your unit tests don't need mock objects anywhere, your project is either very simple or the unit testing is insufficient.

Design can reduce the need of mocked objects to an extent but when using 3rd party APIs, it is not always possible.

Integration tests have a different goal.