views:

494

answers:

3

One way of thinking about this is: if we care about the Design of the code then Easymock is the better choice as it gives feedback to you by its concept of expectations If we care about the maintainability of tests( easier to read,write and having less brittle tests which are not affected much by change), then Mockito seems a better choice.

My question is: - If you have used Easymock in large scale projects, do you find that your tests are harder to maintain? - What are the limitations of Mockito( other than endo testing)

+3  A: 

I'm an EasyMock developer so a bit partial but of course I've used EasyMock on large scale projects.

My opinion is that EasyMock tests will indeed breaks once in a while. EasyMock forces you to do a complete recording of what you expect. This requires some discipline. You should really record what is expected not what the tested method currently needs. For instance, if it doesn't matter how many time a method is called on a mock, don't be afraid of using andStubReturn. Also, if you don't care about a parameter, use anyObject() and so on. Thinking in TDD can help on that.

My analyze is that EasyMock tests will break more often but Mockito ones won't when you would want them to. If prefer my tests to break. At least I'm aware of what was the impacts of my development. This is of course, my personal point of view.

Henri
Yes, I have been thinking the same: with Mockito (and Unitils Mock, a similar mocking API) it's much easier to write tests that continue to happily pass when they shouldn't. I suspect this may be the main reason why Mockito-like APIs, which facilite the creation of excessively "loose" tests, are often considered "easier".
Rogerio
A: 

I don't think you should be too concerned about this. Both Easymock and Mockito can be configured to be 'strict' or 'nice' the only difference is that by default Easymock is strict wheras Mockito is nice.

As with all testing there's no hard and fast rule, you need to balance test confidence against maintainability. I typically find there are certain functional or technical areas that demand a high level of confidence for which I would use 'strict' mocks. For example we probably wouldn't want the debitAccount() method to be called more than once! However there are other cases in which the mock is really little more than a stub so we can test the real 'meat' of the code.

In the early days of Mockito's life API compatibility was a problem but more tools now support the framework. Powermock (a personal favorite) now has a mockito extension

Toby Hobson