Monthly Archives: January 2014

Why is wide usage of PowerMock problematic

twittergoogle_plusrss

Facebooktwittergoogle_plusredditlinkedinmail

There are Java constructs well known for their testability issues:

  • Private methods
  • Static methods
  • Constuctors
  • Final methods or classes

Skilled Java developer following TDD tries to minimize their testability impacts. Don’t want to dive into techniques to enhance testability. They are explained well on Misko Hevery’s blog.

Some developers argue that we have frameworks today (like PowerMock or JMockIt) that are able mock these testability killers. And it’s true. So should we throw factory methods to bin and start using static or singleton classes widely? The answer is NO. Reason is in Java language nature. There isn’t way how to mock mentioned constructs using Java features like inheritance, polymorphism or reflection. Byte-code manipulation is needed. And that is the problem.

Here are some facts about PowerMock:

  • It is using Javassist library for byte-code manipulation
  • It took 1.5 years to make PowerMock + Javaassist compatible with Java7 since its introduction. Here is note from PowerMock change log:
Change log 1.5 (2012-12-04)
---------------------------
Upgraded to Javassist 3.17.1-GA, this means that PowerMock works in Java 7!

I tried to use PowerMock and JMockIt to test some legacy code. The result weren’t acceptable for me. Sometimes there were some strange crashes or clash with JaCoCo test coverage tool (have to say that I didn’t give JMockIt deep chance and abandoned on it immediately after first problems). At the end I always decided to change the production code to enhance testability and use plain Mockito.

If it would be up to me I would exclude byte-code manipulation testing frameworks from technology stack completely. Java8 is coming soon and potential migration of unit tests can be a big problem if it is used widely. It would be ridiculous to wait 1.5 years for Java8 update because of testing framework.

I respect PowerMock and JMockIt projects and people behind them. They are sometimes valuable in cases when you have to deal with legacy code or third party libraries.

twittergoogle_plusrss

Use Mockito to mock autowired fields

twittergoogle_plusrss

Facebooktwittergoogle_plusredditlinkedinmail

EDIT: Field injections are widely considered (including myself) as bad practice. Read here for more info. I would suggest to use constructor injection instead.

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.

Example source code can be downloaded from GitHub.

twittergoogle_plusrss

Mock final class

twittergoogle_plusrss

Facebooktwittergoogle_plusredditlinkedinmail

Foreword

If you already read some other blog post about unusual mocking, you can skip prelude via this link.

I was asked to put together examples how to mock Java constructs well know for their testability issues:

I am calling these techniques unusual mocking. I was worried that such examples without any guidance can be widely used by teammates not deeply experienced in mocking frameworks.

Developers practicing TDD or BDD should be aware of testability problems behind these constructs and try to avoid them when designing their tests and modules. That is the reason why you probably wouldn’t be facing such unusual mocking often on project using these great programming methodologies.

But sometimes you have to extend or maintain legacy codebase that usually contains low cohesive classes. In most cases there isn’t time in current hectic agile world to make such class easy to unit test standard way. When you are trying to unit test such class you often realize that unusual mocking is needed.

That is why I decided to create and share refactoring considerations alongside with examples and workarounds for unusual mocking. Examples are using Mockito and PowerMock mocking frameworks and TestNG unit testing framework.

Mock final class

Refactoring considerations

Change class to non-final (remove final keyword) and test it standard way. This is technique I use always when I can change code of final class.

Usage of PowerMock

Before usage of this example, please carefully consider if it is worth to bring bytecode  manipulation risks into your project. They are gathered in this blog post. In my opinion it should be used only in very rare and non-avoidable cases.

Test shows how to mock final class by PowerMock framework. Example covers:

  1. Mocking of method with return value in final class
  2. Mocking of final void method in final class
  3. Verifying of method calls in final class

Final class:

public final class Plane {
	public static final int ENGINE_ID_RIGHT = 2;
	public static final int ENGINE_ID_LEFT = 1;

	public boolean verifyAllSystems() {
		throw new UnsupportedOperationException("Fail if not mocked!");
	}

	public void startEngine(int engineId) {
		throw new UnsupportedOperationException(
				"Fail if not mocked! [engineId=" + engineId + "]");
	}
}

Class under test:

public class Pilot {
	private Plane plane;

	public Pilot(Plane plane) {
		this.plane = plane;
	}

	public boolean readyForFlight() {
		plane.startEngine(Plane.ENGINE_ID_LEFT);
		plane.startEngine(Plane.ENGINE_ID_RIGHT);
		return plane.verifyAllSystems();
	}
}

Test:

@PrepareForTest(Plane.class)
public class PilotTest extends PowerMockTestCase {
	@Test
	public void testReadyForFlight() {
		Plane planeMock = PowerMockito.mock(Plane.class);
		Pilot pilot = new Pilot(planeMock);

		Mockito.when(planeMock.verifyAllSystems()).thenReturn(true);

		// testing method
		boolean actualStatus = pilot.readyForFlight();

		Assert.assertEquals(actualStatus, true);
		Mockito.verify(planeMock).startEngine(Plane.ENGINE_ID_LEFT);
		Mockito.verify(planeMock).startEngine(Plane.ENGINE_ID_RIGHT);
	}
}

Links

Source code can be downloaded from Github.

Other unusual mocking examples:

twittergoogle_plusrss

Mock static method

twittergoogle_plusrss

Facebooktwittergoogle_plusredditlinkedinmail

Foreword

If you already read some other blog post about unusual mocking, you can skip prelude via this link.

I was asked to put together examples how to mock Java constructs well know for their testability issues:

I am calling these techniques unusual mocking. I was worried that such examples without any guidance can be widely used by teammates not deeply experienced in mocking frameworks.

Developers practicing TDD or BDD should be aware of testability problems behind these constructs and try to avoid them when designing their tests and modules. That is the reason why you probably wouldn’t be facing such unusual mocking often on project using these great programming methodologies.

But sometimes you have to extend or maintain legacy codebase that usually contains low cohesive classes. In most cases there isn’t time in current hectic agile world to make such class easy to unit test standard way. When you are trying to unit test such class you often realize that unusual mocking is needed.

That is why I decided to create and share refactoring considerations alongside with examples and workarounds for unusual mocking. Examples are using Mockito and PowerMock mocking frameworks and TestNG unit testing framework.

Mock static method

Refactoring considerations

  1. No mocking – In theory, static methods should be used only in small utility classes. Their functionality should be simple enough. So there shouldn’t be need to  mock static method.
  2. Converting into Spring/EJB bean – If the functionality in static method isn’t simple enough and mocking is needed, consider converting class into Spring/EJB singleton bean. Such bean can be injected into testing class. This is easily mockable by plain Mockito functionality (see this blog post).

Workaround using Mockito

This is my preferred technique when I need to mock static method. I believe that minor exposing of internal implementation in flavor to enhance testability of testing module is much lower risk for project than fall into bytecode manipulation mocking  framework like PowerMock or JMockIt.

This technique involves:

  • Encapsulation of static methods into default method
  • Partial mock (spy) is used to mock this method during testing

Mockito example covers:

  1. Mocking of encapsulated method with return value
  2. Mocking of encapsulated void method
  3. Verifying of encapsulated method calls

Class under test:

public class HumanityMockito {
	/**
	 * Is used as testing target to demostrate static mocking workaround
	 * 
	 * @param greenHouseGasesList
	 *            list of greenhouse gases amounts to release into atmosphere
	 * @return greenhouse gases levels in atmosphere
	 */
	public double revageAthmoshere(Collection<Integer> greenHouseGasesList) {
		for (int greenhouseGases : greenHouseGasesList) {
			releaseGreenHouseGases(greenhouseGases);
		}
		return monitorRevageOfAthmosphere();
	}

	/**
	 * Void method with default access modifier to be mocked. Wraps static
	 * method call.
	 * 
	 * @param volume
	 *            volume of greenhouse gases to release
	 */
	void releaseGreenHouseGases(int volume) {
		Athmosphere.releaseGreenhouseGases(volume);
	}

	/**
	 * Method with return value and default access modifier to be mocked. Wraps
	 * static method call.
	 * 
	 * @return greenhouse gases level
	 */
	double monitorRevageOfAthmosphere() {
		return Athmosphere.getGreenhouseGassesLevel();
	}
}

Test:

public class HumanityMockitoTest {
	private static final int BILION_TONS_CO2 = 5;
	private static final double GREENGOUSE_GASSES_LEVEL = 393.1;

	@Test
	public void testRevageAthmoshere() {
		HumanityMockito humanity = new HumanityMockito();
		HumanityMockito humanitySpy = Mockito.spy(humanity);

		Mockito.doReturn(GREENGOUSE_GASSES_LEVEL).when(humanitySpy)
				.monitorRevageOfAthmosphere();
		Mockito.doNothing().when(humanitySpy)
				.releaseGreenHouseGases(BILION_TONS_CO2);

		// invoke testing method
		Collection<Integer> greenHouseGassesList = new ArrayList<>(
				Arrays.asList(BILION_TONS_CO2, BILION_TONS_CO2));
		double actualLevel = humanitySpy.revageAthmoshere(greenHouseGassesList);

		Assert.assertEquals(actualLevel, GREENGOUSE_GASSES_LEVEL);
		Mockito.verify(humanitySpy, Mockito.times(greenHouseGassesList.size()))
				.releaseGreenHouseGases(BILION_TONS_CO2);
	}
}

Usage of PowerMock

Before usage of this example, please carefully consider if it is worth to bring bytecode  manipulation risks into your project. They are gathered in this blog post. In my opinion it should be used only in very rare and non-avoidable cases.

Test shows how to mock static method by PowerMock directly. Example covers:

  1. Mocking of static method with return value
  2. Mocking of static void method
  3. Verifying of static method calls

Class under test:

public class HumanityPowerMock {
	public double revageAthmoshere(Collection<Integer> greenHouseGasesList) {
		for (int greenhouseGases : greenHouseGasesList) {
			Athmosphere.releaseGreenhouseGases(greenhouseGases);
		}
		return Athmosphere.getGreenhouseGassesLevel();
	}
}

Test:

@PrepareForTest(Athmosphere.class)
public class HumanityPowerMockTest extends PowerMockTestCase {
	private static final int BILION_TONS_CO2 = 5;
	private static final double GREENGOUSE_GASSES_LEVEL = 393.1;

	@Test
	public void testRevageAthmoshere() {
		PowerMockito.mockStatic(Athmosphere.class);

		Mockito.when(Athmosphere.getGreenhouseGassesLevel()).thenReturn(
				GREENGOUSE_GASSES_LEVEL);

		// call of static method is required to mock it
		PowerMockito.doNothing().when(Athmosphere.class);
		Athmosphere.releaseGreenhouseGases(BILION_TONS_CO2);

		// invoke testing method
		Collection<Integer> greenHouseGassesList = new ArrayList<>(
				Arrays.asList(BILION_TONS_CO2, BILION_TONS_CO2));
		HumanityPowerMock humanity = new HumanityPowerMock();
		double actualLevel = humanity.revageAthmoshere(greenHouseGassesList);

		Assert.assertEquals(actualLevel, GREENGOUSE_GASSES_LEVEL);

		// call of static method is required to verify it
		PowerMockito.verifyStatic(Mockito.times(greenHouseGassesList.size()));
		Athmosphere.releaseGreenhouseGases(BILION_TONS_CO2);
	}
}

Links

Source code can be downloaded from Github.

Other unusual mocking examples:

twittergoogle_plusrss

Mock final method

twittergoogle_plusrss

Facebooktwittergoogle_plusredditlinkedinmail

Foreword

If you already read some other blog post about unusual mocking, you can skip prelude via this link.

I was asked to put together examples how to mock Java constructs well know for their testability issues:

I am calling these techniques unusual mocking. I was worried that such examples without any guidance can be widely used by teammates not deeply experienced in mocking frameworks.

Developers practicing TDD or BDD should be aware of testability problems behind these constructs and try to avoid them when designing their tests and modules. That is the reason why you probably wouldn’t be facing such unusual mocking often on project using these great programming methodologies.

But sometimes you have to extend or maintain legacy codebase that usually contains low cohesive classes. In most cases there isn’t time in current hectic agile world to make such class easy to unit test standard way. When you are trying to unit test such class you often realize that unusual mocking is needed.

That is why I decided to create and share refactoring considerations alongside with examples and workarounds for unusual mocking. Examples are using Mockito and PowerMock mocking frameworks and TestNG unit testing framework.

Mock final method

Refactoring considerations

Change method to non-final (remove final keyword) and test it standard way. This is technique I use always when I can change code of final method.

Usage of PowerMock

Before usage of this example, please carefully consider if it is worth to bring bytecode  manipulation risks into your project. They are gathered in this blog post. In my opinion it should be used only in very rare and non-avoidable cases.

Test shows how to mock final method by PowerMock framework. Example covers:

  1. Mocking of final method with return value
  2. Mocking of final void method
  3. Verifying of final method calls

Class with final methods:

public class Bike {
	public final void shiftGear(boolean easier) {
		throw new UnsupportedOperationException("Fail if not mocked! [easier="
				+ easier + "]");
	}

	public final int getGear() {
		throw new UnsupportedOperationException("Fail if not mocked!");
	}
}

Class under test:

public class Rider {
	private Bike bike;

	public Rider(Bike bike) {
		this.bike = bike;
	}

	public int prepareForUphill() {
		int gear = bike.getGear();
		for (int idx = 0; idx < 2; idx++) {
			bike.shiftGear(true);
			gear++;
		}
		return gear;
	}
}

Test:

@PrepareForTest(Bike.class)
public class RiderTest extends PowerMockTestCase {
	private static final int TESTING_INITIAL_GEAR = 2;

	@Test
	public void testShiftGear() {
		Bike mock = PowerMockito.mock(Bike.class);

		Rider rider = new Rider(mock);
		Mockito.when(mock.getGear()).thenReturn(TESTING_INITIAL_GEAR);

		// invoke testing method
		int actualGear = rider.prepareForUphill();

		Assert.assertEquals(actualGear, TESTING_INITIAL_GEAR + 2);
		Mockito.verify(mock, Mockito.times(2)).shiftGear(true);
	}
}

Links

Source code can be downloaded from Github.

Other unusual mocking examples:

twittergoogle_plusrss