Using Reflection To Create Mock Objects

Well-established tools like Mockito and EasyMock offer a powerful range of features for defining and interacting with mock objects. I use both heavily in my unit tests, and would recommend them to anyone looking for a mocking framework. Sometimes, however, a real (i.e. non-proxied) collaborator is called for, or adding third-party libraries may not be an option. In most cases, a suitable object could be instantiated by calling the constructor and setting it as a dependency to the object under test. Suppose though that we have the following ‘Footballer’ class, and we want to write a test for the ‘getAvgGoalsPerGame()’ method:

We know that unless both of the ‘gamesPlayed’ and ‘goalsScored’ are initialised, a NullPointerException will be thrown, so we might initially write the test as follows:

This is all well and good, but when the number of fields that need to be set increases, the unit tests quickly become littered with code required to set up the mocks. In this case, it makes sense to perform the initialisation outside the test class. An alternative solution avoiding Reflection would be to create Builders for the classes to be mocked. An article describing this approach can be found here.

A generic MockObjectPopulator is therefore required, and an outline of what this might look like is given in the example below:

In the above implementation, a map is constructed to associate the field names with their values, and this is then applied to the object passed as a parameter. Where the desired value for a field is not explicitly given in the map, a value is retrieved from the ‘DefaultValues’ class based on the declared type. An implementation of the DefaultValues class is given below. Note that it can be loaded with values either explicitly or through dependency injection.

Returning to our Footballer example, we can now write the unit test as follows:

All of the code in this example is now on GitHub, so feel free to reuse anything that you have found useful.


3 Responses to “Using Reflection To Create Mock Objects”

  1. Good Idea, This is very valid point and having a custom Mock Creator especially a reusable one helps to quickly write unit test and test with real like input and parameters of domain object.

    Top 10 multi-threading interview questions in Java

    Posted by Javin @ noClassdeffoundError in Java | January 2, 2012, 15:15
  2. Hi Richard,

    thanks for this interesting post. This is surely a way of dealing with creation of objects, however, IMHO not the most recommended one. I would rather suggest using Test Data Builders approach (see, which result in much cleaner and readable code.

    Reflection in test code? No thank you, unless this is really the only option (which is rare).

    Tomek Kaczanowski

    Posted by Tomek | January 2, 2012, 21:15
  3. Thanks for the feedback. Tomek – I take your point, and can see the value in the Builders approach. However, I still feel that there is room for the above solution as well. Even if there are a large number of classes to mock, this MockObjectPopulator can be used immediately, allowing the developer to start writing the tests without having to first invest in writing the individual Builders.

    That said, there are certainly instances where I would favour using a Builder to Reflection, and I’ve added the link to my post.

    Posted by rich | January 3, 2012, 21:12

Leave a Reply

Email Updates

Subscribe to this blog and receive notifications of new posts by email.


Richard Ashworth
Technical Lead at Goodlord
Experienced software engineer and technical lead. Passionate about functional programming, agile methods and domain-driven design. Check out my blog at


Read this blog in your favourite news reader: