JMockit An automated testing toolkit for Java

Recording strict expectations

Invocations that must occur only as specified can be explicitly recorded using strict expectations. Some mocking APIs only support the recording of expectations that are not strict, while also supporting the explicit verification of matching invocations after the call to the class under test. JMockit supports both models in a seamless API.

Explicit verification

Strict expectations are always verified implicitly and automatically. For those that are not recorded strictly (regular or non-strict expectations), invocations can be explicitly verified after the unit under test was exercised.

No method call to switch from record to replay

Expectations are recorded before the unit under test is exercised, at which time they will (potentially) be replayed. Some mocking APIs have a special method that needs to be explicitly called in the test method, so that the toolkit will know that when the next invocation occurs it will be a "replayed" one, instead of another recording. (In EasyMock, this special method is replay(mock) or replayAll(); in jMock, it's checking(expectations).)

No extra code for implicit verification

Some mocking APIs, like EasyMock and jMock, require extra code to enable the verification of missing invocations at the end of a test. In the case of EasyMock, a verify(mock) or verifyAll() method call is required in each test method. With jMock, one of the following alternatives is needed: 1) a JUnit 3.8 test class needs to extend MockObjectTest; 2) a JUnit 4 test class must be annotated with @RunWith(JMock.class); or 3) the Mockery#assertIsSatisfied() method needs to be called at the end of each test method. The Mockito and Unitils Mock APIs do not support implicit verification at all, so this item isn't applicable.

Easier argument matching based on properties of value objects

Sometimes an invocation argument is an object containing one or more properties of interest, which must have their values at replay time verified in the test. Custom matchers (which all mocking APIs allow without significant differences) provide the ability to implement argument matching behavior of any complexity, and can therefore be used in this situation. The problem, though, is that it takes too much code to create a new matcher class. There are three alternative approaches to deal with this issue in a behavior-oriented mocking API: 1) make deep copies of invocation arguments and then compare the property values in the two instances through reflection; 2) allow argument values to be captured into special objects or variables which can later be verified through regular assertions; and 3) verify arguments through regular assertions in a custom validation method executed for each matching invocation. Approach 1 is used by Unitils Mock. Approach 2 is provided by EasyMock and Mockito, and therefore also available when using PowerMock. JMockit supports approaches 2 and 3, through the withCapture() method and Delegate objects, respectively.