ICE09 . playing with java, scala, groovy and spring .

Playing with Spring

Archive for January, 2011

Mocking and Stubbing with Mockito

Posted by ice09 on January 9, 2011



Let’s assume there is a new requirement for an existing CRM-like system: send a mail to all customers with a balance greater than 1000. Since we are not allowed to access the database directly, we will have to use existing services.


Since we are using Spring, the configuration is obvious, the services are injected, that’s it.


However, for testing purposes, we want to mock the services. By examining the classes and methods, we will see why mocking is necessary, but not enough in this case.


Only the interfaces of the services are shown, they are mocked anyway.


public interface MailService { 
    void sendMails(List<customer> customers); 



public interface CustomerDao { 

    List<customer> getCustomers(); 


This is the class under test, the filter method should be tested.

public class CustomerService { 
    private CustomerDao customerDao; 
    private MailService mailService; 
    public void notifyCustomersWithBalanceGreaterThan(long cbalance) { 
        List<customer> notificationList = new ArrayList<customer>(); 
        List<customer> customers = customerDao.getCustomers(); 
        for (Customer customer : customers) { 
            if (customer.getBalance() > cbalance) { 



How do we test if everything worked? There is no result object to check, since mails are sent. Here mocking comes into play, a breeze with Mockito.

public class TestClass {

	private @Mock CustomerDao customerDao;
	private @Mock MailService mailService;
	private @InjectMocks CustomerService customerService = new CustomerService();

	private @Captor ArgumentCaptor<List<Customer>> customerCaptor;

	public void setup() {

	public void testIt() {
		//preparation (stubbing)

		//verification (mocking)
		//has customerDao be called correctly?
		verify(customerDao, times(1)).getCustomers();

		//have the mails be sent?
		//is the list of customers to notify correct? 
		assertEquals(2, customerCaptor.getValue().size());
		assertEquals(new Customer(3, "eva", "mustermann", 2000), customerCaptor.getValue().get(0)); 
		assertEquals(new Customer(6, "hanna", "mustermann", 1001), customerCaptor.getValue().get(1)); 

	private List<Customer> prepareList() {
		List<Customer> customers = new ArrayList<Customer>();
		customers.add(new Customer(1, "hans", "mustermann", 100));
		customers.add(new Customer(2, "max", "mustermann", 1000));
		customers.add(new Customer(3, "eva", "mustermann", 2000));
		customers.add(new Customer(4, "anna", "mustermann", 0));
		customers.add(new Customer(6, "hanna", "mustermann", 1001));
		return customers;


The mocking part is straightforward. However, we have to stub as well, since we want the CustomerDao to actually return our prepared Customer list. No problem with Mockito (search for Test Spy to see why there are differences in Mocking frameworks regarding the support of Mocking, Stubbing or both – then being a Test Spy).

Dependency injection

Really interesting is the wiring of the components. The MockitoJUnitRunner.class is used to run the Unittest, we do not use Spring for this test. But magically, after calling MockitoAnnotations.initMocks(this) the @Mock annotated Mocks are injected into the @InjectMocks annotated class automatically. This being great already, we are furthermore using the @Captor annotation to create a argument captor for all List arguments. Now we can examine the submitted list with Customers to sent mail to and determine, if the correct Customers have been filtered.
So, we have a nice dependency injection, combined with stubbing and mocking. Mockito is really powerful (and much easier to use than similar Mocking frameworks), you can even partially stub objects. However, there should be a really good reason for doing this…

Posted in Uncategorized | 1 Comment »