File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Testing and the fly likes Status quo of mocking frameworks Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Status quo of mocking frameworks" Watch "Status quo of mocking frameworks" New topic

Status quo of mocking frameworks

Adrian Kulasek

Joined: May 25, 2012
Posts: 3
A question to Tomek Kaczanowski: your book focuses mainly on Mockito but I belive you've tested other mocking frameworks before choosing it. AFAIK almost all mocking frameworks follow the same ideology, i.e. the let you declare mock, set some expectations on it and the verify those expectations. Apart from the framework-specific differences, do you think that this way of doing things is good as it is? Or maybe, after all this time of using mocks you have some thoughts and considerations about the future of mocking? Is there anything you would change, add or remove from the mocking process?
Tomek Kaczanowski
Ranch Hand

Joined: Oct 26, 2005
Posts: 40

Hi Adrian,

you are right that currently available mocking frameworks are very similar in terms of what can be done using them.

The only pain I feel when mocking is that it makes my tests brittle by making them too tightly coupled with implementation. Mockito helps to avoid this to some extent by "not worrying about the unexpected", but even this does not solve the whole issue. Obviously, if you look at the general idea of verification of messages sent from tested object to collaborators, you will see that there is no much you could do - your tests simply have to repeat some of the implementation of the tested object. However there is still room for improvement when it comes to stubbing, as I learned few months ago.

To make long story short, a new framework - Komarro (based on Mockito by the way) - makes your expectations much less fragile. Usually in the tests you say something like (copied directly from Komarro's website):

but with Komarro you can write:

which means that the fact that SUT uses or maybe or anything else is not relevant anymore - the right person will be returned even if the implementation changes.

Is this the future of mocking frameworks? It definitely solves some issue with tests maintainability, which is a real pain, so I would expect this idea should gain some popularity.

Not sure if this is an answer to your question, but that is all I have right now.

Tomek Kaczanowski
Book author: Practical Unit Testing with TestNG and Mockito
Adrian Kulasek

Joined: May 25, 2012
Posts: 3
Thanks for your reply. I think you've exactly nailed the problem that concerned me since I've started using mocks. That's the main problem of EasyMock for me - tests are very sensitive to any changes in the implementation of a tested method. And just yesterday I've found out about Komarro in your other reply on this forum. I'm definitely going to try it out soon.
I agree. Here's the link:
subject: Status quo of mocking frameworks
jQuery in Action, 3rd edition