It’s only been a few days since the Mockito 1.8.3 release and I have to say that for a minor release there’s a lot I like about it!

What I like about the new annotations is the ability to have test cases that are completely free of @Before. Observe this example of a class that takes a text input string, translates it to an AuctionEvent, and fires it off to an AuctionEventListener:

@RunWith(MockitoJUnitRunner.class)
public class AuctionMessageTranslatorTest {
	@Mock AuctionEventListener listener;
	@InjectMocks AuctionMessageTranslator translator = new AuctionMessageTranslator();

	@Test
	public void shouldSendAnEventToTheListener(){
		translator.sendMessage("SOL Version: 1.1; Event: PRICE;");

		verify(listener).handleEvent(any(AuctionEvent.class));
	}
}

This is a first step, to just verify an event is passed to the listener (we don’t care about it’s contents yet). @Mock creates a mock on each test method run, and @InjectMocks will pass mocks to any matching setters or constructors.

Now I’ll implement a little code to make the example pass.

public class AuctionMessageTranslator {
	private AuctionEventListener listener;
	public void setListener(AuctionEventListener listener) {
		this.listener = listener;
	}

	public void sendMessage(String message) {
		listener.handleEvent(new AuctionEvent());
	}
}

Doesn’t do much… so let’s add a new example that verifies the contents of the message sent to the listener. Since this object is created by the translator (translating a string to an object) we’ll use an argument captor to capture and verify it’s value.

@RunWith(MockitoJUnitRunner.class)
public class AuctionMessageTranslatorTest {
	@Mock AuctionEventListener listener;
	@Captor ArgumentCaptor<AuctionEvent> arg;
	@InjectMocks AuctionMessageTranslator translator = new AuctionMessageTranslator();

	@Test
	public void shouldSendAnEventToTheListener(){
		translator.sendMessage("SOL Version: 1.1; Event: PRICE;");

		verify(listener).handleEvent(any(AuctionEvent.class));
	}

	@Test
	public void shouldSendAnEventWithNamePrice(){
		translator.sendMessage("SOL Version: 1.1; Event: PRICE;");

		verify(listener).handleEvent(arg.capture());

		assertThat(arg.getValue().getName(), equalTo("PRICE"));
	}
}

It fails, so we implement the code to make it pass:

	public void sendMessage(String message) {
		listener.handleEvent(parseEvent(message));
	}

	private AuctionEvent parseEvent(String message) {
		AuctionEvent auctionEvent = new AuctionEvent();
		auctionEvent.setName(message.split(";")[1].split(":")[1].trim());
		return auctionEvent;
	}

This passes as the argument passed to the listener does indeed contain the event name. This is a little ugly, so let’s refactor it a little bit with our test providing a nice safety net:

	public void sendMessage(String message) {
		listener.handleEvent(parseEvent(message));
	}

	private AuctionEvent parseEvent(String message) {
		AuctionEvent auctionEvent = new AuctionEvent();
		auctionEvent.setName(unpackMessage(message).get("Event"));
		return auctionEvent;
	}

	private Map<String, String> unpackMessage(String message) {
		Map<String, String> pairs = new HashMap<String, String>();
		for(String pairString : message.split(";")){
			String[] pair = pairString.split(":");
			pairs.put(pair[0].trim(), pair[1].trim());
		}
		return pairs;
	}

Looks good, and the test case for it is pretty clean although it has a lot of annotations. We could change the injection strategy to use constructor injection since we don’t really want the object to even exist without a listener:

@RunWith(MockitoJUnitRunner.class)
public class AuctionMessageTranslatorTest {
	@Mock AuctionEventListener listener;
	@Captor ArgumentCaptor<AuctionEvent> arg;
	@InjectMocks AuctionMessageTranslator translator = new AuctionMessageTranslator(listener);
...
}

As long as the @InjectMocks annotation is present, the MockitoJunitRunner will initialize the mocks do they’re available for injection. Drop the @InjectMocks annotation off, and it fails with a null pointer exception.

One interesting thing of note when using @InjectMocks with setter injection is if you do something silly like the following:

@RunWith(MockitoJUnitRunner.class)
public class AuctionMessageTranslatorTest {
	@Mock AuctionEventListener listener;
	@Mock AuctionEventListener listener2;
	@Captor ArgumentCaptor>AuctionEvent> arg;
	@InjectMocks AuctionMessageTranslator translator = new AuctionMessageTranslator();
	...
}

It will inject the first @Mock, not the second. Verifications against listener will work, while verifications against listener2 will fail as it was never injected.

Tomorrow I’ll include some examples of using the @Spy annotation as well as the different answer types you can configure @Mock annotated mocks with as of 1.8.3.

No tags

I’m currently in chapter 12 of Growing Object Oriented Software Guided By Tests and thought I’d share another good tidbit from one of the asides:

Put Tests in a Different Package

We’ve adopted a habit of putting tests in a different package from the code they’re exercising. We want to make sure we’re driving the code through its public interfaces, like any other client, rather than opening up a package-scoped back door for testing.

Good point! Almost everytime I’ve found my self expose a method that should be private as protected or default it’s been because that method was really in gross violation of Single Responsibility Principle and I’ve often taken such code and extracted it to a separate object.

Thoughts?

No tags

Szczepan has announced on the Mockito user mailing list that 1.8.3 of Mockito has been released. This released includes several small (but useful) additions as well as bug fixes.

The two parts of this release I like are the new annotations @Spy, @Captor, and @injectMocks. These add to the already useful @Mock annotation to simplify test setup tremendously. Additionally, the @Mock annotation is now configurable so you can add different Mock/Stub styles; previously @Mock only supported the default mock behavior, now you can configure it to RETURNS_MOCKS, CALLS_REAL_METHODS, etc.

This release also includes a feature I requested that can be useful when trying to get legacy code under test, something I call deep stubs. Ever been in the situation where you have code with something like this in the middle of it:

someCollaborator.getFoo().doBarThings().getBaz().execute().processResult();

Normally to stub this call, you’ll have to mock every object returned by each method call, and then stub the last one. Examples for code like this can be a little verbose, but now you can just @Mock the aggregate root and do something like:

given(someColllaborator.getFoo().doBarThings().getBaz().execute().processResult).willReturn(resultObject);

Just remember friends, this is only good for legacy code… if you are already writing your code exemplar first to drive your design, you should know better than to make your object know too many details about it’s neighbors.

This release also includes a patch I submitted to stop having all of the examples in a test run when trying to run a single one in eclipse and intelliJ when using MockitoJunitRunner.

For a complete list of features/fixes, see the release notes.

No tags

I’ll be giving a presentation at Lambda Lounge this Thursday on Behavior Driven Development With Jspec. If you’re in the St.Louis area come on by and learn about BDD and how you can use it to drive your design. I’ll be using jspec to demonstrate how to build a functioning feature for a javascript library driven by small, iterative examples.

No tags