Does JMockit have any drawbacks at all?

Question

This comparison shows, that JMockit has several advantages over other frameworks.

Are there also any advantages that one of the others (JMock, EasyMock, Mockito, Unitils, PowerMock + Mockito/EasyMock) has over JMockit?

Answer 1

Three drawbacks:

• You must use a Java agent to do bytecode instrumentation.
• You can't use the signed junit.jar file shipped with Eclipse.
• You have to learn a mock API. (In contrast to a stub object)

You can always discuss if it's a good thing to be able to mock a final class like JMockit can. Unless it's legacy code, refactoring is usually a better alternative.

With IDEs like Eclipse, I find myself using tool support to generate stubs inside the test class more frequently than mocking (JMockit, Mockito, etc.) in the recent time. The advantage with this approach is that it's very simple. This is especially nice when you have a team with many developers and some of them don't like testing and have little motivation to learn a mocking framework. Also, stub implementations don't have framework limitations!

If you're open for stubbing as an alternative, you should check out Robert C. Martin's blog about mocking and stubbing here and here

Else, it looks very good! Although I have only experience with JMock, EasyMock and basic knowledge with JMockit.

Answer 2

I've recently adopted a project that uses JMockit and I think the quality of the code has certainly suffered as a result of the library's ability to mock out static and private methods.

The tests are very brittle because implementation details contained in private methods are being tested (so if I change how the class does something it can break tests, even if what the class does has not been affected).

The code is also littered with calls to static methods - if the developers had not had the ability to mock these out then I think they would have made more effort to de-couple things a little better.