Chapter 7. Points of Controversy

Listing 7.28. Use of the ArgumentCaptor class

public class PIMTest {

private static		final int	ONE_HOUR = 60;
private static		final Date START_DATE = new Date();
private	static	final int	MILLIS_IN_MINUTE = 1000 * 60;
private	static	final Date END_DATE = new Date(START_DATE.getTime()
+ ONE_HOUR		* MILLIS_IN_MINUTE);

@Test

public void shouldAddNewEventToCalendar() { Calendar calendar = mock(Calendar.class); PIM pim = new PIM(calendar); ArgumentCaptor<Meeting> argument

= ArgumentCaptor.forClass(Meeting.class);

pim.addMeeting(START_DATE, ONE_HOUR);

verify(calendar).addEvent(argument.capture()); Meeting meeting = argument.getValue(); assertEquals(START_DATE, meeting.getStartDate()); assertEquals(END_DATE, meeting.getEndDate());

}

}

An object of the ArgumentCaptor class is created, which will gather information on arguments of the type Meeting.

The addEvent() method’s having been called is verified, and Mockito is instructed to capture arguments of this method call.

The actual argument to the addEvent() method is extracted from the ArgumentCaptor object. What we have here are classic assertions which verify that the right object has been passed as an argument to the addEvent() method.

As shown in Listing 7.28, we can use ArgumentCaptor to verify arguments passed to collaborators. This solution has some positive features:

•it does not rely on the equals() method of the domain object (in our case, of the Meeting class),

•it can be used to test arbitrary properties of arguments,

•"normal" assertions are used to specify our expectations regarding the arguments.

In general, Mockito does a good job of facilitating the task of verifying a collaborator’s arguments. However, as the Mockito documentation warns, having to use ArgumentCaptor might be indicative that the code is not well-designed:

Over reliance on capturing arguments would be a code smell in my opinion as most well abstracted code should not need to do this. However for testing legacy code and interactions with outside systems ArgumentCaptors can be very useful.

— Mockito Documentation

7.8. Conclusions

The issues discussed in this chapter are nothing short of real-life problems. You will encounter them mostly when working with legacy code, but also when making decisions about how to design the

173

Chapter 7. Points of Controversy

application you are working on right now. And you will have to make your choices. In this section we have discussed some important dilemmas, in the hope that when the time comes, you will have enough knowledge to choose the right solution to the problem you are faced with. Maybe you will redesign your application and avoid the problem of private methods testing, or maybe you will use the sort of bruteforce techniques that will enable you to do that. This depends on the context of the problem in hand, and on your own personal experience and preferences.

174