Post summary: Why mocking is needed in unit testing and how to do it with Mockito.
Unit testing
By definition, unit testing is a process in which the smallest testable parts of an application, called units, are individually and independently tested for proper operation. Smallest testable unit in Java is a method. Public methods are the only one exposed to outside world, so only they are subject to unit testing.
Mocking
Unit tests focus on a particular piece of code that needs to be exercised. In most of the cases, this code relies on external dependencies. Those dependencies have to be controlled, so only code under test is exercised. Removing dependencies is done with a test double. Test doubles are objects that look and behave like their release-intended counterparts but are actually simplified versions of them which reduce the complexity and facilitate testing. Test doubles are fakes, stubs, and mocks.
Mockito
Mockito is the most famous mocking framework for Java. It provides all mocking features needed for proper unit testing, except mocking of static methods. Static methods can be mocked with PowerMock. It is a Mockito’s wrapper that provides same API plus static method mocking and other features. In PowerMock examples and why better not to use them post, I have shown how to use PowerMock and its features.
Example class for unit test
Code shown in examples below is available in GitHub java-samples/junit repository. We are going to unit test a class called Locator that internally uses another class LocatorService:
public class Locator {
private final LocatorService locatorService;
public Locator(LocatorService locatorService) {
this.locatorService = locatorService;
}
public Point locate(int x, int y) {
if (x < 0 || y < 0) {
return new Point(Math.abs(x), Math.abs(y));
} else {
return locatorService.geoLocate(new Point(x, y));
}
}
}
The example above is pretty simple. If we pass point with some negative coordinates method locate() returns point with positive coordinates. If coordinates are positive then search via LocatorService is done. This class represents some external API that our code is calling. Since there is no control over this API and internal structure is not know it should be mocked in the unit tests. As stated above unit tests are focused on a specific piece of code, a unit.
Initialising a mock
As described in Mockito’s documentation a way to mock some object is: List mockedList = mock(List.class); Another way, that is used in current examples is to annotate the filed that is going to be mocked with @Mock and annotate JUnit test class with @RunWith(MockitoJUnitRunner.class). In this way Mockito runner does the initialization behind the scenes:
@RunWith(MockitoJUnitRunner.class)
public class LocatorTest {
@Mock
private LocatorService locatorServiceMock;
}
Control mock’s behavior
The whole idea of having a mock is to be able to control its behavior. If mock is called it should respond in a predictable manner. This is done with when() method:
when(locatorServiceMock.geoLocate(any(Point.class)))
.thenReturn(new Point(11, 11));
When mock’s geoLocate() method is being called with any given point object it always returns new Point with coordinates X=11 and Y=11. If this is not enough, more elaborate scenarios can be used:
when(locatorServiceMock.geoLocate(new Point(5, 5))).thenReturn(new Point(50, 50));
when(locatorServiceMock.geoLocate(new Point(1, 1))).thenReturn(new Point(11, 11));
If locator class is called with a point with coordinates (5, 5) then new point with coordinates (50, 50) is returned. If mock is called with a point with coordinates (1, 1) then point with (11, 11) is returned. In any other cases, null is returned by default.
Nota bene: in order to work properly object used to call the mocked method (Point is the current example) should have properly implemented equals() method otherwise java.lang.Object‘s equals() method is used, which just compared the references. Examples above will not work, as Point doesn’t have equals() method properly overridden.
Depending on tests that have to be conducted more precise control over mock’s response could be needed. This is done with thenAnswer() mock’s method:
when(locatorServiceMock.geoLocate(any(Point.class)))
.thenAnswer(new Answer<Point>() {
@Override
public Point answer(InvocationOnMock invocationOnMock) throws Throwable {
Object[] args = invocationOnMock.getArguments();
Point caller = (Point) args[0];
if (caller.getX() == 5 && caller.getY() == 5) {
return new Point(50, 50);
} else if (caller.getX() == 1 && caller.getY() == 1) {
return new Point(11, 11);
} else {
return null;
}
}
});
Call to invocationOnMock.getArguments() returns array with arguments that mock’s geoLocate() method was called with. In the current example, it is only one argument from type Point, so it is cast and saved to new Point object inside caller variable. If coordinates are (5, 5) then new point with coordinates (50, 50) are returned. If coordinates on input are (1, 1) then new point (11, 11) is returned. In all other cases, null is returned.
Verify mock was interacted with
In order to verify execution path is correct, Mockito provides a way to check if a certain method on the mock has been called and how many times. This is done with verify() method. To confirm no more methods are called on this specific mock instance then verifyNoMoreInteractions() is used:
verify(locatorServiceMock, times(1)).geoLocate(new Point(1, 1));
verifyNoMoreInteractions(locatorServiceMock);
The example above verifies that mock’s geoLocate() method was called with a specific point with coordinates (1, 1). If it is not important which object is passed to the method then any(Point.class) can be used.
Nota bene: the example above will not work as there is no equals() method implemented on point class, so Mockito is using java.lang.Object’s equals() method by default that compares only the references. Point class is intentionally left without equals method to demonstrate how such situations can be solved. How to solve this obstacle is shown in Assert Mockito mock method arguments if no equals() method implemented post.
Putting it all together
All snippets above are put together is one simple unit test that covers all the possible paths for Locator’s locate() method, but obviously not all the test conditions:
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.runners.MockitoJUnitRunner;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;
import static org.mockito.Matchers.any;
import static org.mockito.Mockito.when;
@RunWith(MockitoJUnitRunner.class)
public class LocatorTest {
private static final Point TEST_POINT = new Point(11, 11);
@Mock
private LocatorService locatorServiceMock;
private Locator locatorUnderTest;
@Before
public void setUp() {
when(locatorServiceMock.geoLocate(any(Point.class)))
.thenReturn(TEST_POINT);
locatorUnderTest = new Locator(locatorServiceMock);
}
@Test
public void testLocateWithServiceResult() {
assertEquals(TEST_POINT, locatorUnderTest.locate(1, 1));
}
@Test
public void testLocateLocalResult() {
Point expected = new Point(1, 1);
assertTrue(arePointsEqual(expected, locatorUnderTest.locate(-1, -1)));
}
private boolean arePointsEqual(Point p1, Point p2) {
return p1.getX() == p2.getX()
&& p1.getY() == p2.getY();
}
}
When locatorServiceMock is called with any then TEST_POINT is returned. No matter that Point has no equals() method defined, assertEquals() in testLocateWithServiceResult() passes because code refers one and the same object. Helper method arePointsEqual() is needed in testLocateLocalResult() though. Code coverage report in IntelliJ IDEA is:
Optimise
Next step is to improve test coverage by adding more unit tests. Copy/paste is not an option, so in post Data driven testing with JUnit parameterized tests I have described how to make data-driven tests in JUnit.
Conclusion
Mocking is mandatory when developing unit tests. Mockito is a convenient mocking library for Java. It is possible to control what mock returns if called with whatever value or if called with a specific value. Mockito allows verification on which of mock’s methods has been called and how many times.
