Why do we need mocking frameworks like Easymock , JMock or Mockito?

We use hand written stubs in our unit tests and I'm exploring the need for a Mock framework like EasyMock or Mockito in our p开发者_高级运维roject.

I do not find a compelling reason for switching to Mocking frameworks from hand written stubs.

Can anyone please answer why one would opt for mocking frameworks when they are already doing unit tests using hand written mocks/stubs.

Thanks

The simple answer is we do not need them.

Nor do we need other existing frameworks, but using Mocking frameworks makes our lives easier. As developers we can spend more time on the problem at hand, rather than creating or carrying out what mocking frameworks can do.

"I do not find a compelling reason for switching to Mocking frameworks from hand written stubs."

I was exactly the same. Why should I bother learning a mocking framework? Hand written stubs do fine.

A few points come to mind, mainly the fact that after a while your tests become obscure with test stubs. What you are refering to when using hand written stubs are known as test extensions. You extend code to enable what mocking frameworks do. In other words you write code to stub, or return values depending on what happens. This takes time, and effort. Not to mention space. A mocking framework can do all this in a matter of lines.

The benefits of a mocking framework are:

• Easier (subjective, but after a while you will not write hand written implementations)
• Less Code (frameworks allow you to create a mock in a matter of lines, rather than full class declarations)
• Follows DRY (you won't end up repeating mock implementations)

The biggest benefit comes to when you require mock objects. Having to hand write code to check if a method was called, how many times and so forth is a mini task in itself. If someone else has done so, and created a throughly tested, well documented framework, it wouldn't make sense not to use it. Just like any framework, you can go along fine without it, but sometimes using the right tool makes the job a lot easier.

You might want to read Martin Fowler's Mocks Aren't Stubs article. The basic difference is this:

• A stub's job is to return known results to all calls
• A mock additionally expects calls to come in a specific order, with specific parameters, and will throw an exception when these expectations are not met.

There are some error condition that cannot be tested for with stubs. On the other hand, tests using mocks are often much less stable.

While stubs can be written manually with reasonable effort, Mocks would require far more work. And a good mocking framework can make writing stubs faster and easier as well.

Just like every other developer I find myself writing code instead of using the existing solution - the "not invented here" syndrome.

Your question suggest that you prefer to write the classes you need to fake/mock twice instead of use a framework that would do that for you. Using a mocking framework frees you from needing to write, refactor and update your hand rolled mocks whenever you change the faked object.

In other words using a mocking framework is just like any other 3rd party library e.g. ORM - someone else wrote the code so you don't have to.

I started the same way (writing mocks by hand) and by now I have almost completely switched over to EasyMock.

I find that using EasyMock is usually both faster and more flexible.

Typically the very first time I need a mock, I can have it in a couple of lines of code with EasyMock, whereas by hand I need to implement the needed interface (fair enough, this can be generated by an IDE like IntelliJ) and then add the necessary code to produce the needed response and/or to allow sensing the effects of calls to it.

Fine, one might say, that's a one-time cost only. The next time I can just reuse the hand written mock happily... I found that's often not the case. In another test I might need a mock of the same class with different behaviour. E.g. different methods are called, and/or different result is expected. A specific case is when the mock is expected to throw an exception in one test case, but not in another. Fine, I can add some parameters to it which control the behaviour dynamically. Then for the next test, some more parameters to control more behaviour... so I end up with an ever more complicated mock implementation, which is a dependency for ever more unit tests - posing also a risk of inadvertently breaking older tests.

As opposed to this, with EasyMock I can configure my mocks independently for each test. Thus the behaviour is explicitly controlled and visible within the unit test code itself, and there is no risk of side effects.

Not to mention that with EasyMock you can verify that the required methods are called in the required order, if you need to (and I do, every now and then). Implementing this by hand (especially in a generic fashion) would be quite pain in the neck, for no added benefit.

Sometimes it might be easier to create mocks in a declarative manner and it can help you write some sorts of behaviours easier using the framework than by hand. Another small advantage might be also that by using the mocking framework you are being explicit about mocking.