About Lubos Krnac

Lubos is a Java/JavaScript developer. His religion is constantly improve his developments skills according to best practices. Strongly believes that TDD drives better design and nicely decoupled code. Past experience include C++, Assembler and C#.

Use Mockito to mock autowired fields

Dependency injection is very powerful feature of Inversion of Control containers like Spring and EJB. It is always good idea to encapsulate injected values into private fields. But encapsulation of autowired fields decreases testability.

I like the way how Mockito solved this problem  to mock autowired fields. Will explain it on example. (This blog post expects that you are little bit familiar with Mockito syntax, but it is self-descriptive enough though.)

Here is first dependency of testing module. It is Spring singleton bean. This class will be mocked in the test.
 

@Repository
public class OrderDao {
	public Order getOrder(int irderId){
		throw new UnsupportedOperationException("Fail is not mocked!");
	}
}

Here is second dependency of testing class. It is also Spring component. This class will be spied (partially mocked) in test. Its method calculatePriceForOrder will be invoked unchanged. Second method will be stubbed.

@Service
public class PriceService {
	public int getActualPrice(Item item){
		throw new UnsupportedOperationException("Fail is not mocked!");
	}

	public int calculatePriceForOrder(Order order){
		int orderPrice = 0;
		for (Item item : order.getItems()){
			orderPrice += getActualPrice(item);
		}
		return orderPrice;
	}
}

And here is class under test. It  autowires dependencies above.

@Service
public class OrderService {

	@Autowired
	private PriceService priceService;

	@Autowired
	private OrderDao orderDao;

	public int getOrderPrice(int orderId){
		Order order = orderDao.getOrder(orderId);
		return priceService.calculatePriceForOrder(order);
	}
}

Finally here is test example. It uses field level annotations:

  • @InjectMocks – Instantiates testing object instance and tries to inject fields annotated with @Mock or @Spy into private fields of testing object
  • @Mock – Creates mock instance of the field it annotates
  • @Spy – Creates spy for instance of annotated field
public class OrderServiceTest {
	private static final int TEST_ORDER_ID = 15;
	private static final int TEST_SHOES_PRICE = 2;   
	private static final int TEST_SHIRT_PRICE = 1;

	@InjectMocks
	private OrderService testingObject;

	@Spy
	private PriceService priceService;

	@Mock
	private OrderDao orderDao;

	@BeforeMethod
	public void initMocks(){
		MockitoAnnotations.initMocks(this);
	}

	@Test
	public void testGetOrderService(){
		Order order = new Order(Arrays.asList(Item.SHOES, Item.SHIRT));
		Mockito.when(orderDao.getOrder(TEST_ORDER_ID)).thenReturn(order);

		//notice different Mockito syntax for spy
		Mockito.doReturn(TEST_SHIRT_PRICE).when(priceService).getActualPrice(Item.SHIRT);
		Mockito.doReturn(TEST_SHOES_PRICE).when(priceService).getActualPrice(Item.SHOES);

		//call testing method
		int actualOrderPrice = testingObject.getOrderPrice(TEST_ORDER_ID);

		Assert.assertEquals(TEST_SHIRT_PRICE + TEST_SHOES_PRICE, actualOrderPrice);
	}
}

So what happen when you run this test:

  1. First of all TestNG framework picks up @BeforeMethod annotation and invokes initMocks method
  2. This method invokes special Mockito call (MockitoAnnotations.initMocks(this)) to initialize annotated fields. Without this call, these objects would be null. Common mistake with this approach is to forget this invocation.
  3. When all the test fields are populated with desired values, test is called.

This example doesn’t include Spring context creation and Spring’s annotations are here only as examples for usage against production code. Test itself doesn’t include  any dependency to Spring and ignores all its annotations. In fact there could be used EJB annotations instead or it can be running against plain (non IoC managed) private fields.

Developers tend to think about MockitoAnnotations.initMocks(this) call as unnecessary overhead. But it is actually very handy, because it resets testing object and re-initializes mocks. You can use it for example

  • When you have various test methods using same annotated instances to ensure that various test runs doesn’t use same recorded behavior
  • When repetitive / parametrized tests are used. For example you can include this call into test  method itself and receive spy object as test parameter (as part of test case). This ability is very sexy in conjunction to TestNG @DataProvider feature (Will explain this in different blog post).

@Spy annotated object can be created in two ways

  • Automatically by Mockito framework if there is default (non-parametrized) constructor
  • Or explicitly initialized (e.g. when there is only non-default constructor)

Testing object annotated by @InjectMocks can be also initialized explicitly.

 

Reference: Use Mockito to mock autowired fields from our JCG partner Lubos Krnac at the http://lkrnac.net/ blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

8 Responses to "Use Mockito to mock autowired fields"

  1. Hi! For TestNG this code will work only if you have a single test method. If you have a second test method then you need to manually reset the mocks, otherwise their behaviour will be memorized. Check – https://code.google.com/p/mockito/issues/detail?id=304

    • Hi Marcin,

      I created additional tests to verify if some behaviour would be memorized:

      Created additional two tests:
      @Test(priority=1)
      public void dummyTest1(){
      System.out.println(“dummyTest1″);
      Order order = new Order(Arrays.asList(Item.SHOES, Item.SHIRT));
      Mockito.when(orderDao.getOrder(TEST_ORDER_ID)).thenReturn(order);
      int actualOrderPrice = testingObject.getOrderPrice(TEST_ORDER_ID);
      Assert.assertEquals(TEST_SHIRT_PRICE + TEST_SHOES_PRICE, actualOrderPrice);
      }

      @Test(priority=2)
      public void dummyTest2(){
      System.out.println(“dummyTest2″);
      int actualOrderPrice = testingObject.getOrderPrice(TEST_ORDER_ID);
      Assert.assertEquals(TEST_SHIRT_PRICE + TEST_SHOES_PRICE, actualOrderPrice);
      }

      It’s obvious that if behaviour would be reused from original test, both would pass.
      But they failed because the behaviour was reset.

      FAILED: dummyTest1
      java.lang.UnsupportedOperationException: Fail is not mocked!
      at net.lkrnac.testingexamples.mockautowired.PriceService.getActualPrice(PriceService.java:8)
      at net.lkrnac.testingexamples.mockautowired.OrderService.getOrderPrice(OrderService.java:17)
      at net.lkrnac.testingexamples.mockautowired.OrderServiceTest.dummyTest1(OrderServiceTest.java:60)

      FAILED: dummyTest2
      java.lang.NullPointerException
      at net.lkrnac.testingexamples.mockautowired.PriceService.calculatePriceForOrder(PriceService.java:13)
      at net.lkrnac.testingexamples.mockautowired.OrderService.getOrderPrice(OrderService.java:17)
      at net.lkrnac.testingexamples.mockautowired.OrderServiceTest.dummyTest2(OrderServiceTest.java:67)

      I also verified order of invocation to be sure that original test was first:
      testGetOrderService
      dummyTest1
      dummyTest2

      So this approach is fine and mockito resets mocks with MockitoAnnotations.initMocks(this);call

      I also verified this:
      testingObject instance was reused accross tests
      spy instance was reused across tests (but behaviour wasn’t memorized)
      mock instance wasn’t reused across tests (each test new mock)

    • Forgot to mention in previous reply:
      This example uses TestNG 6.8.7 and Mockito 1.9.5

      • The code won’t work if you have constructor injection in OrderService (I don’t know why but I thought that you have one ;) ):

        OrderService:

        public class OrderService {

        private final PriceService priceService;

        private final OrderDao orderDao;

        public OrderService(PriceService priceService, OrderDao orderDao) {
        this.priceService = priceService;
        this.orderDao = orderDao;
        }

        public int getOrderPrice(int orderId){
        Order order = orderDao.getOrder(orderId);
        return priceService.calculatePriceForOrder(order);
        }
        }

        Now add verification of execution of orderDao:

        Mockito.verify(orderDao, times(1)).getOrder(TEST_ORDER_ID);

        so the test will look like this:

        @Test(invocationCount = 2)
        public void testGetOrderService(){
        Order order = new Order(Arrays.asList(Item.SHOES, Item.SHIRT));
        Mockito.when(orderDao.getOrder(TEST_ORDER_ID)).thenReturn(order);

        //notice different Mockito syntax for spy
        Mockito.doReturn(TEST_SHIRT_PRICE).when(priceService).getActualPrice(Item.SHIRT);
        Mockito.doReturn(TEST_SHOES_PRICE).when(priceService).getActualPrice(Item.SHOES);

        //call testing method
        int actualOrderPrice = testingObject.getOrderPrice(TEST_ORDER_ID);

        Mockito.verify(orderDao, times(1)).getOrder(TEST_ORDER_ID);
        Assert.assertEquals(TEST_SHIRT_PRICE + TEST_SHOES_PRICE, actualOrderPrice);
        }

        And it will fail. To remove that issue check this -> https://code.google.com/p/mockito/issues/detail?id=304 .

        • Ok. This example was about mocking field injections.
          If you are using constructor injection (which should be preferred way how to do dependency injection), you don’t have to use @InjectMocks/@Spy/@Mock annotations at all.
          You can create testing object via constructor and pass in mocks/spies created by Mockito.mock/Mockito.spy calls.
          This is the way how I am testing constructor injection and it’s probably reason why I didn’t experience problems you are pointing out.

          In my opinion @InjectMocks/@Spy/@Mock are handy only for field injections. They are doing reflection magic to inject mocks/spies into private fields.

  2. Ok. This example was about mocking field injections.
    If you are using constructor injection (which should be preferred way how to do dependency injection), you don’t have to use @InjectMocks/@Spy/@Mock annotations at all.
    You can create testing object via constructor and pass in mocks/spies created by Mockito.mock/Mockito.spy calls.
    This is the way how I am testing constructor injection and it’s probably reason why I didn’t experience problems you are pointing out.

    In my opinion @InjectMocks/@Spy/@Mock are handy only for field injections. They are doing reflection magic to inject mocks/spies into private fields.

    • I disagree – Of course you can do it manually but that’s the idea behind automatization that you don’t do it manually. Anyway as for your example – of course you were right in terms of field injection so sorry for the comment ;)

      • Please don’t apologize for the comments.

        Manual approach is (in my opinion) much more readable for people who are not familiar with @InjectMocks/@Spy/@Mock features. I don’t see any benefit using these annotations for constructor injection.

Leave a Reply


four × = 24



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close