Difference between Mockito and JMockit

Table of contents

Reading Time: 2 minutes

A Brief analysis on Mockito And Jmockit

Mockito	JMockit
1. We can achieve Static method/constructor mocking by the combination of Mockito with Powermock.	1. Static method/constructor can be mocked directly in JMockit.
2. The Mockito API contains several inconsistencies in the syntax used for invocations to mocked methods. In the record phase, we have calls like when(mock.mockedMethod(args))… while in the verify phase this same call will be written as verify(mock).mockedMethod(args). Notice that in the first case the invocation to mocked method is made directly on the mock object, while in the second case it is made on the object returned by verify(mock).	2. JMockit has no such inconsistencies because invocations to mocked methods are always made directly on the mocked instances themselves. (With one exception only: to match invocations on the same mocked instance, an onInstance(mock) call is used, resulting in code like onInstance(mock).mockedMethod(args); most tests won’t need to use this, though.
3. Mockito does not have any built-in code coverage report. We face many conflicts and clashes while using JoCoCo with Mockito+PowerMock. But we can use Cobertura as an explicit tool to have full coverage.	3. Jmockit has built-in coverage report and full support for JaCoCo.
4. Mockito has a relatively low learning curve as compared to JMockit.	4. JMockit Has the steeper learning curve as compared to Mockito.
5. Custom argument matching is relatively complex as compared toJMockit.	5. custom argument matching is easy as compared to Mockito.
6. Mockito is most known as compared to JMockit, so the community will be bigger as compared to JMockito.	6. JMockit is less known compared to Mockito, so the community will be not as big as Mockito.
7. Mockito uses ‘proxy API’ design architecture.	7. JMockit is based on Java 1.5 instrumentation API framework.

Finally, the JMockit Testing Toolkit has a wider scope and more ambitious goals than other mocking toolkits, in order to provide a complete and sophisticated developer testing solution. A good API for mocking, even without artificial limitations, is not enough for the productive creation of tests. An IDE-agnostic, easy to use, and well-integrated Code Coverage tool is also essential, and that’s what JMockit Coverage aims to provide.

Another piece of the developer testing toolset which will become more useful as the test suite grows in size is the ability to incrementally rerun tests after a localized change to production code. this is also included in the Coverage tool.

I’d like to add another argument to the discussion that google trends graph gives 7 and 100 for JMockit and Mockito respectively ass on 28/10/2017 and the number of users is also important when choosing a framework. On the other hand, Mockito has been voted as the best mocking framework on StackOverflow. But we can also consider that newer technology is always better and Jmockit fits into this category.

References:- https://stackoverflow.com/, http://jmockit.org/