This document provides an overview of unit testing and mocking frameworks. It discusses why we unit test and mock, defines common mocking terminology like mocks, stubs and dummies. It then provides an introduction to the Mockito mocking framework, including its syntax and limitations. Examples are provided to demonstrate mocking with Mockito for a user report generation system.

1. PAUL CHURCHWARD
SENIOR CONSULTANT, CAPITAL MARKETS PRACTICE - TORONTO
What the
Mockito?
Mocking with Mockito …
The Java mocking framework for unit testing

2. Why we (unit) test
What is mocking
Why we mock
How to mock

3. Why we (unit) test
 Verify logic works as intended
 Simulate how code behaves under different circumstances (e.g. negative testing)
 Ensure logic continues to works as designed after you’ve written it

4. I wish I wrote a (unit) test!
Consider this example …
You write a report for another system to consume and the columns must be
in alphabetical order.
public void generateReport()
{
List<String> columns = columnFactory.getColumns();
FooBarReport report = reportService.generateReport(ReportType.FooBar);
writeReportToDisk(report);
}
Output:
FooBar Report
2015-03-18 13:00
================
A|B|C|D|E|F
2|6|2|4|2|6
1|3|5|9|11|
==
2 rows

5. I wish I wrote a (unit) test!
… 5 months later a change is made to ColumnFactory to spit out columns in
reverse alphabetical order and is pushed to production.
Your report now looks like this:
Output:
FooBar Report
2015-08-18 13:00
================
F|E|D|C|B|A
6|2|4|2|6|2
|11|9|5|3|1
==
2 rows
... The system consuming this report fails to read it and blows up in production.

6. What is mocking?
 Mock objects are used in unit testing to simulate the behaviour of real objects.
 Sometimes you want to modify the behaviour of a class during a unit test.
This is why you use mocks e.g: providing canned responses to methods or verifying that
a method was invoked the expected number of times.
 Different types of mocks exist for different uses: mocks, stubs, and dummies

7. Mocking nomenclature
System Under Test:
The class you are testing the behaviour of.
Collaborator:
A dependent class that is needed for the system under test to execute properly. We are not interested in testing the behaviour of the collaborator. We are interested in testing how the system under test
interacts with the collaborator.
Dummy Mock:
An object that is only used to fulfil the contract of an API and never actually used. Similar to an empty shell. Method invocations on the object do not cause any sate change; in essence they do nothing.
Mock:
Very confusing term! Similar to a dummy, a mock does not have a working implementation. It is used to verify that API calls are executed on a collaborator as expected; meaning the correct number of
times (or not at all) and with the correct parameters. We will call this a verify mock for simplicity.
Stub:
A stub provides canned responses when invoked.
For example: To test how an order-placing-service behaves when the stock-checking-service shows the item is out of stock, you can stub of the stock-checking-service to always return 0 items in stock. A
stub gives you the ability to setup canned responses during unit tests without having to put test code in production classes.
Partial Mock:
A partial mock invokes the real methods of an object by default, unless they are stubbed. This should be used rarely; the need for this is a code smell and should be refactored.

8. Why we mock
 Mocking makes testing easier by giving us tools to make more powerful tests. Without
mocking, we would have to add these tools to production classes.
Typical cases for mocking:
 Verifying that a method was called the correct number of times (or not at all).
 Providing canned responses to verify they are handled correctly.
 Speeding up test execution by creating dummies for collaborator objects that will not affect
the result of the test.
e.g: DAO classes, classes writing to file system

9. Mockito Syntax
 Test class needs to be annotated with
@RunWith(MockitoJUnitRunner.class)
This initializes the mocks declared in the test class before each test case is run.
There are other ways to initialize mocks, but this is the preferred way.
 Verify-mocks, stubs and dummies are created via the @Mock annotation
@Mock
private OrdersDAO mockedOrderDAO;
No implementation needs to be provided. Mockito magic will handle that. Invoking methods on it will not affect the state of the object.
You can use this mock to verify that methods are invoked the expected number of times and with the correct arguments.
aRealObject.doSomething(mockedOrderDAO);
//verify getOrders() on the DAO is invoked once by aRealObject.doSomething()
Mockito.verify(mockedOrderDao, Mockito.times(1)).getOrders();
You can stub methods on this mocked object to provide canned responses.
//When getOrders() is invoked by aRealObject.doSomething(), return a canned list of results. Don’t talk to the DB
when(mockedOrderDAO.getOrders()).thenReturn(fetchCannedListOfOrders());
aRealObject.doSomething(mockedOrderDAO);

10. Partial Mocking / Code Smell
 Partial mocks allow real methods of an object to be invoked unless they are explicitly stubbed.
Mockito accomplishes this with the @Spy annotation
@Spy
//Note you need to provide an implementation, unlike when using @Mock
private OrderService orderService = new OrderService();
As it is now, invoking any method on oderService will call the real method.
We can stub a method on the partially mocked object to provide a canned response. Calls to the getOrders() method will not be forwarded to the
real getOrders() method.
doReturn(fetchCannedOrders()).when(orderService).getOrders();
 Partial mocks are generally indicative of a code smell. The standard approach to mocking is to mock or stub collaborators and test how
the system under test interacts with them, while not mocking any part of the system under test.
The need to stub or mock parts of the system under test or call real methods on a collaborator are highly unusual and screams refactor
me.
You will find these cases usually break the single responsibility principle. Following this principle makes unit testing much easier.

11. Mockito Limitations
 Cannot mock or stub static methods
 Cannot mock or stub final methods, it will silently call the real method
 Cannot mock or stub private methods
 Cannot stub or verify a shared instance of a mock in different threads
 Cannot stub equals() or hashcode() – nor should you want to!
These are all reasonable constraints. If you find yourself needing to do any of these,
rethink your code.

12. Mocking examples
 Let’s walk through examples of using Mockito to write unit tests for a user report system.
Tests include:
 A happy path through the ReportFactory class, ensuring the report is generated correctly
 Ensuing the report is generated correctly for users with uncommon properties (e.g.: no manager)
 Ensure the report is written to the database
*As this is a unit test, we will mock out the database layer and just ensure the ReportGenerator calls the appropriate DAO
method
Samples Here:
https://www.dropbox.com/sh/crn7v3crzoa3p0n/AAC0m6H_wLawiRU0NvieFgPMa?dl=0

13. Additional Resources
Mocks aren’t stubs – Martin Fowler
http://martinfowler.com/articles/mocksArentStubs.html
Mockito API
http://docs.mockito.googlecode.com/hg/org/mockito/Mockito.html
Mockito tag on StackOverflow
http://stackoverflow.com/questions/tagged/mockito