Archive for November 10th, 2008
Drink that mockito! (Part 1)
I know a lot of us have heard of Mockito already (although the logo IS something new I noticed today) but the one thing that’s making me write about it today is the fact that the website says that to date there has only been over 4500 downloads, excluding maven users. Only 4500 downloads? What’s up with that? Mockito is the easiest to understand Java mocking framework I’ve encountered over the past 2 years. Yes, I do know that I haven’t around in the software community for that long but recently I’ve been trying to digest and comprehend tests written in EasyMock but it’s just quite impossible.
Do yourself and your team a favor and download Mockito and use it. Your sanity will thank you for it. Your tests will be:
1. Cleaner and clearer – There is a clear separation between actual method calls and the interaction and behavior that you are trying to test
2. Easy to refactor – no strings for method names
3. Plugged into the Behavior-Driven-Development way of structuring given-when-then test scenarios
I shall try and post example tests written in both EasyMock and Mockito to prove the vast difference in clarity and quality. Stay tuned!
>> Edited
My friend Mark reckons that Mockito makes it much harder to realize that you have designed something badly because writing tests for it is less painful. If one had a lot of dependencies in a class, one would need to stub out a massive amount of stuff before actually getting to gist of what one is testing.
I think that is true to a certain extent: if you’re not practicing TDD, or if you’re dealing with legacy code. But I don’t think that was the intent of Mockito. The idea was to promote clean and simple test code so that developers would also write clean and simple application code.



