Chapter 9. Organization Of Tests
(e.g. there is no need for a balance variable to exist - assertEquals(60, account.getBalance()) would
suffice). This approach brings a lot of clarity, and a little bit of redundancy, to every test method.
Another thing to notice is the single assertion within each test method. This is something I criticized in Section 7.4; however, it starts to make sense with the BDD approach.
9.4.2. Mockito BDD-Style
In contrast to JUnit, Mockito facilitates writing tests BDD-style. It provides a BDDMockito class, which allows you to use a given() method in the same way as we have been using the Mockito.when() method up to now (i.e. to set expectations on test doubles). This makes Mockito tests more BDD-like. Listing 9.5 shows this.
Listing 9.5. Mockito test - BDD style
import static org.mockito.BDDMockito.given;
public class BddMockitoTest {
private static final int ID_USER = 329847;
@Test
public void shouldReturnClient() { // given
User USER = new User();
UserDAO dao = mock(UserDAO.class); 
UserService service = new UserService(dao); 
given(dao.getUser(ID_USER)).willReturn(USER); 
// when
User user = service.loadUser(ID_USER);
// then
assertEquals(USER, user);
}
}
Importing of a given() method of the BDDMockito class. Setting up the SUT (service) and injecting a test double (dao).
Use of a given() method helps to keep the BDD given/when/then rhythm. It is equivalent to
when(dao.getUser(ID_USER)).thenReturn(USER);, but does not use a when() method, which would
be confusing as we are still in the "given" part of the test code.
As shown in the listing above, this amounts to a nice piece of syntactic sugar, but nothing groundbreaking. However, it does help to express the rhythm of a BDD test, which is a good thing.
9.5. Reducing Boilerplate Code
If you work with Mockito a lot, you might be interested in cutting down the boilerplate code of test doubles creation. All those instances of myMock = mock(SomeClass.class), which seem to show up in every test method, are really annoying, right? The good news is that Mockito makes it possible to get rid of the boilerplate code. In this section we will take a look at Mockito’s annotations and its one-liner stubbing feature.
199
Chapter 9. Organization Of Tests
Consistency is good. Whether you decide to use the features presented in this section or choose not to do so, be consistent about this.
Listing 9.6 shows two simple classes which will be used to demonstrate these new Mockito features. Their names - SUT and Collaborator - reveal their purpose clearly, in both cases.
Listing 9.6. SUT and Collaborator classes
public class Collaborator { public String doSth() {
return "xyz";
}
}
public class SUT {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) { this.collaborator = collaborator;
}
public String useCollaborator() { return collaborator.doSth(); 
}
}
The default value returned by the doSth() method is "xyz",
A simple delegating method which is supposed to return what collaborator returns.
A typical test for this sort of functionality is shown below. I have decided to use a setUp() method this time, because I believe this is a more common scenario.
Listing 9.7. Typical test with a lot of boilerplate code
public class BoilerplateCodeTest {
private Collaborator collaborator; private SUT sut;
@Before
public void setUp() { sut = new SUT();
collaborator = Mockito.mock(Collaborator.class); sut.setCollaborator(collaborator);
}
@Test
public void shouldReturnABC() { when(collaborator.doSth()).thenReturn("abc"); assertEquals("abc", sut.useCollaborator());
}
}
This is where the repetitive code occurs – the creation of the SUT, the creation of test doubles and injecting them.
The question is whether we can do anything about this.
200
Chapter 9. Organization Of Tests
Please bear in mind that under "normal" circumstances, the boilerplate code section is much larger than shown in Listing 9.7. Usually there will be more than one test double in your code. Multiply it by the number of tests which use test doubles and the reason for cutting down the size of all of the set up activities becomes evident.
9.5.1. One-Liner Stubs
The first thing we can do is to make the creation and stubbing of collaborator slightly shorter. Mockito allows for one-line stubbing, which is shown in Listing 9.8.
Listing 9.8. Reducing boilerplate code with one-line stubbing
public class OneLinerStubbingTest {
private Collaborator collaborator = when(mock(Collaborator.class).doSth())
.thenReturn("abc").getMock(); private SUT sut;
@Before
public void setup() { sut = new SUT();
sut.setCollaborator(collaborator);
}
@Test
public void shouldReturnABC() { assertEquals("abc", sut.useCollaborator());
}
}
In this line, a test double gets created and stubbed. Note the getMock() method at the end of the invocation chain.
No test double creation in setUp() method.
Personally, I am not a big fan of this feature. Its usage does not bring serious code reduction, and, in my opinion, slightly obscures the view. If you plan to use it, I would recommend putting the actual creation and stubbing code in your setUp() method, so all creation code is in one place.
9.5.2. Mockito Annotations
Now let us move on to the main point of boilerplate code reduction. An example of what can be achieved is shown in Listing 9.9.
201
Chapter 9. Organization Of Tests
Listing 9.9. Creating test doubles using Mockito annotations
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;
@RunWith(MockitoJUnitRunner.class) public class AnnotationsTest {
@Mock private Collaborator collaborator; private SUT sut;
@Before
public void setup() { sut = new SUT();
sut.setCollaborator(collaborator);
}
@Test
public void shouldReturnABC() { when(collaborator.doSth()).thenReturn("abc"); 
assertEquals("abc", sut.useCollaborator()); 
}
}
Importing of Mockito annotations,
This line instructs JUnit to use a specialized Mockito runner. It will result in the creation of test doubles for all fields marked with an @Mock annotation.
The collaborator, which will be replaced by a test double, is marked with an @Mock annotation. There is nothing surprising here about the way the test double of collaborator is used. It gets injected into the SUT (using a setter) and is instructed to return a canned value.
This test proves that the test double behaves as instructed: it returns "abc" instead of the default
"xyz".
Now, that was interesting. There was no explicit line creating a test double, and yet it behaved as if it had been created in the usual way.
In the case shown in Listing 9.9, not much has been gained. In fact, for a single test with one test double, the number of lines grows. However, if you use this technique for a whole suite, with many test methods and many test doubles, then the decrease in the number of code lines might be visible.
In (rare) cases where you have more than one collaborator of the same kind, you could use the name attribute of an @Mock annotation to instruct Mockito about which field of the SUT should be replaced with which test double. Please consult the Mockito documentation for details.
Nice, but we can go even further, and inject test doubles into the SUT using annotations. For example:
202
Chapter 9. Organization Of Tests
Listing 9.10. Injecting test doubles using Mockito annotations
@RunWith(MockitoJUnitRunner.class) public class InjectMocksTest {
@Mock private Collaborator collaborator;
@InjectMocks private SUT sut = new SUT();
@Test
public void shouldReturnABC() { when(collaborator.doSth()).thenReturn("abc"); assertEquals("abc", sut.useCollaborator());
}
}
@InjectMocks tells Mockito to …well, to inject mocks into this particular object.
In contrast to the previous version of the setUp() method, here there is no SUT creation and no setting of collaborator.
Wow! No setting of collaborator, and still the execution of the useCollaborator() method does not fail with a NullPointerException! In reality the collaborator is injected to the SUT behind the scenes. Mockito does this by matching available test doubles with the SUT’s fields.
You will be even more surprised when you remove the setter (the setCollaborator() method) from the SUT class, and watch the test still work. This is because Mockito does not really execute setters to set fields, but uses a reflection mechanism to modify them directly.
Now, let us summarize and discuss what we have just been learning about.
In our pursuit of better, cleaner, more readable test code, we have learned about Mockito annotations - @Mock and @InjectMocks. Both can be used to cut down the boilerplate code related to the creation and injection of mocks. By using them, we have:
•shortened the setup phase of the test code,
•got rid of repetitive, boilerplate test double creation and code setting.
However, in passing the responsibility for test double creation and injection over to Mockito, we must agree to certain things, namely:
•that the SUT must be created before injection happens (see the example in Listing 9.10),
•that Mockito uses reflection, which can lower code coverage measures (and that it bypasses setters).
Using @Mock and @InjectMocks annotations might have both good and bad effects on the readability of your code. On the one hand the code becomes more concise, and ceases to be cluttered up with repetitive statements. On the other, with larger tests you can lose track of "what was created where", and achieve the opposite effect – namely, that of diminished readability.
Please make sure you read carefully about the annotations presented in this section, in the Mockito documentation. There are some gotchas which might take you by surprise if and when you use them.
Mockito offers several more annotations similar to the @Mock annotation; however, their use is very limited. Please consult the Mockito documentation to learn about them.
203