Mockito vs JMockit ~ IT BLOG

Thursday, December 31, 2020

Mockito vs JMockit

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.

Comparison of Stubs & Drivers:

Even though both stubs and drivers are dummy/pseudo codes, there are various features of these two components that are different from each other. Therefore, to signify their differences, here is a comparison of stubs and drivers.

Stubs	Drivers
1. Used in Top-Down Integration Testing.	1.Used in Bottom-Up Integration Testing.
2. A piece of code that emulates the called function.	2. A piece of code that emulates a calling function.
3. Stubs stimulates the activity of missing and not developed modules.	3. Drivers pass test cases to another code and invoke modules under testing.
4. These are created when high level modules are tested and lower level modules are not developed.	4. These are created when lower level modules are tested and higher level modules are not yet developed.