Maintenance projects are not fun compared to greenfield projects, but they sure provide most of the meat for this blog. This week saw me not checking the production code but the tests. What you see in tests reveals much of how the production code itself is written. And it’s a way to change things for the better, with less risks.

At first, I only wanted to remove as much PowerMock uses as possible. Then I found out most Mockito spies were not necessary. Then I found out that Mockito mocks were initialized in 3 different ways in the same file; then usages of both given() and when() in the same class, then usages of when() and doReturn() in the same class…​ And many more areas that could be improved.

In this post, I’ll limit myself to sum up the 3 ways to initialize your mocks in your test class: pick and choose the one you like best, but please stick with it in your class (if not your project). Consistency is one of the pillar of maintainability.

Reminder Unit-testing is an important foundation of Software Quality (but not the only one!). As Object-Oriented Design is to make multiple components each with a dedicated responsibility, it’s crucial to make sure each of those components perform its tasks in a adequate manner. Hence, we have to feed a component with known inputs and check the validity of the outputs. Thus, testing the component in isolation requires a way to replace the dependencies with both input providers and output receivers that are in our control. Mockito is such a framework (among others) that let you achieve that. Creating those mocks in the first place can be done using different ways (I’ll use Mockito wording in place of the standard one).

One-by-one explicit mocking The first and most straightforward way is to use Mockito’s mock() static method. public class FooTest { private Foo foo ; @Before public void setUp () { foo = Mockito . mock ( Foo . class ); } @Test public void test_foo () { Bar bar = Mockito . mock ( Bar . class ); // Testing code go there } } It might be the most verbose one, but it’s also the easiest to understand, as the API is quite explicit. Plus it’s not dependent on a testing framework. And you may mock On the downside, if you’ve got a high number of dependencies, you need to initialize them one by one - but perhaps having such a high number is a sign of bad design?

All-in-one general mocking call The second option aims to fix this problem (the number of calls, not the design…​). It replaces all method calls by a single call that will mock every required attribute. In order to tell which attribute should be a mock, the @Mock annotation must be used. public class FooTest { @Mock private Foo foo ; @Mock private Bar bar ; @Before public void setUp () { MockitoAnnotations . initMocks (); } @Test public void test_foo () { // Testing code go there } } Here, the 2 Mockito.mock() calls (or more) were replaced by a single call. On the downside, a local variable had to be moved to an attribute in order for Mockito to inject the mock. Besides, you have to understand what how the initMocks() method works.

JUnit runner The last option replaces the explicit initMocks() call with a JUnitRunner. @RunWith ( MockitoJUnitRunner . class ) public class FooTest { @Mock private Foo foo ; @Mock private Bar bar ; @Test public void test_foo () { // Testing code go there } } This option alleviates the pain to write the single method call. But it has the downsides of option 2, plus it binds you to JUnit, foregoing other alternatives such as TestNG.