1. Introduction

With this article, we'll be starting a new series centered around the mocking toolkit JMockit.

In this first installment we'll talk about what JMockit is, its characteristics and how mocks are created and used with it.

Later articles will focus on and go deeper into its capabilities.

2. JMockit

2.1. Introduction

First of all, let's talk about what JMockit is: a Java framework for mocking objects in tests (you can use it for both JUnit and TestNG ones).

It uses Java's instrumentation APIs to modify the classes' bytecode during runtime in order to dynamically alter their behavior. Some of its strong points are its expressibility and its out-of-the-box ability to mock static and private methods.

Maybe you're new to JMockit, but it's definitely not due to it being new. JMockit's development started in June 2006 and its first stable release dates to December 2012, so it's been around for a time now (current version is 1.24 at the time of writing the article).

2.2. Maven Dependency

First, we'll need to add the jmockit dependency to our project:


2.3. The Expressibility of JMockit

As told before, one of the strongest points of JMockit is its expressibility. In order to create mocks and define their behavior, instead of calling methods from the mocking API, you just need to define them directly.

This means that you won't do things like:


Instead, expect things like:

new Expectation() {
    result = value; 
    times = 2;

It might seem that it is more code, but you could simply put all three lines just on one. The really important part is that you don't end up with a big “train” of chained method calls. Instead, you end up with a definition of how you want the mock to behave when called.

If you take into account that on the result = value part you could return anything (fixed values, dynamically generated values, exceptions, etc), the expressiveness of JMockit gets even more evident.

2.4. The Record-Replay-Verify Model

Tests using JMockit are divided into three differentiated stages: record, replay and verify.

  1. On the record phase, during test preparation and before the invocations to the methods we want to be executed, we will define the expected behavior for all tests to be used during the next stage.
  2. The replay phase is the one in which the code under test is executed. The invocations of mocked methods/constructors previously recorded on the previous stage will now be replayed.
  3. Lastly, on the verify phase, we will assert that the result of the test was the one we expected (and that mocks behaved and were used according to what was defined in the record phase).

With a code example, a wireframe for a test would look something like this:

public void testWireframe() {
   // preparation code not specific to JMockit, if any

   new Expectations() {{ 
       // define expected behaviour for mocks

   // execute code-under-test

   new Verifications() {{ 
       // verify mocks

   // assertions

3. Creating Mocks

3.1. JMockit's Annotations

When using JMockit, the easiest way to use mocks, is to use annotations. There are three for creating mocks (@Mocked, @Injectable and @Capturing) and one to specify the class under testing (@Tested).

When using the @Mocked annotation on a field, it will create mocked instances of each and every new object of that particular class.

On the other hand, with the @Injectable annotation, only one mocked instance will be created.

The last annotation, @Capturing will behave like @Mocked, but will extend its reach to every subclass extending or implementing the annotated field's type.

3.2. Passing Arguments to Tests

When using JMockit is possible to pass mocks as test parameters. This is quite useful for creating a mock just for that one test in particular, like some complex model object that needs a specific behavior just for one test for instance. It would be something like this:

public class TestPassingArguments {
   private Foo mockForEveryTest;

   private Bar bar;

   public void testExample(@Mocked Xyz mockForJustThisTest) {
       new Expectations() {{


This way of creating a mock by passing it as a parameter, instead of having to call some API method, again shows us the expressibility we're talking about since the beginning.

3.3. Complete Example

To end this article, we'll be including a complete example of a test using JMockit.

In this example, we'll be testing a Performer class that uses Collaborator in its perform() method. This perform() method, receives a Model object as a parameter from which it will use its getInfo() that returns a String, this String will be passed to the collaborate() method from Collaborator that will return true for this particular test, and this value will be passed to the receive() method from Collaborator.

So, the tested classes will look like this:

public class Model {
    public String getInfo(){
        return "info";

public class Collaborator {
    public boolean collaborate(String string){
        return false;
    public void receive(boolean bool){
        // NOOP

public class Performer {
    private Collaborator collaborator;
    public void perform(Model model) {
        boolean value = collaborator.collaborate(model.getInfo());

And the test's code will end up being like:

public class PerformerTest {

    private Collaborator collaborator;

    private Performer performer;

    public void testThePerformMethod(@Mocked Model model) {
        new Expectations() {{
    	    model.getInfo();result = "bar";
    	    collaborator.collaborate("bar"); result = true;
        new Verifications() {{

4. Conclusion

With this, we'll wrap up our practical intro to JMockit. If you want to learn more about JMockit, stay tuned for future articles.

The full implementation of this tutorial can be found on the GitHub project.

4.1. Articles in the Series

All articles of the series:

Generic bottom

I just announced the new Learn Spring course, focused on the fundamentals of Spring 5 and Spring Boot 2:

Comments are closed on this article!