Tag Archives: Unit Testing

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

Mock constructor

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 constructor

Refactoring considerations

  • If your testing method creates instance/s of some type, there are two possibilities what can happen with these instances
    • Created instance/s are returned from testing method. They are in this case part of the testing method API. This can be tested by verifying against created instances rather than constructor method call. If target instances doesn’t have hashCode/equals contract implemented, you can still create test specific comparator to verify created data.
    • Created instances are used as parameter/s passed to some dependency object. This dependency object of testing class is most probably mocked. In this case it’s better idea to capture arguments of dependency method call and verify them. Mockito offers good support for this.
    • Created instances are temporary objects that support testing method job. In this case you shouldn’t care about creation of these instances, because you should treat testing module as black box that doing the job, but you don’t know how.
  • Create factory class for constructing instances and mock it standard way.
  • If that fits to requirement -> Abstract factory design pattern

Workaround using Mockito

This is my preferred technique when I need to mock constructor. 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:

  • Encapsulating the constructor into method with default access modifier
  • Partial mock (spy) is used to mock this method during testing

Mockito example covers:

  1. Partial mocking of factory method
  2. Verifying of mocked factory method call

Class under test:

public class CarFactoryMockito {
	Car carFactoryMethod(String type, String color) {
		return new Car(type, color);
	}

	public Car constructCar(String type, String color) {
		carFactoryMethod(type, color);
		// ... other logic needed to be tested ...
		return carFactoryMethod(type, color);
	}
}

Test:

public class CarFactoryMockitoTest {
	private static final String TESTING_TYPE = "Tatra";
	private static final String TESTING_COLOR = "Black";

	@Test
	public void testConstructCar() {
		CarFactoryMockito carFactory = new CarFactoryMockito();
		CarFactoryMockito carFactorySpy = Mockito.spy(carFactory);

		Car mockedInstance = Mockito.mock(Car.class);
		Mockito.doReturn(mockedInstance).when(carFactorySpy)
				.carFactoryMethod(TESTING_TYPE, TESTING_COLOR);

		// invoke testing method
		Car actualInstance = carFactorySpy.constructCar(TESTING_TYPE,
				TESTING_COLOR);

		Assert.assertEquals(actualInstance, mockedInstance);
		// ... verify other logic in constructCar() method ...
		Mockito.verify(carFactorySpy, Mockito.times(2)).carFactoryMethod(
				TESTING_TYPE, TESTING_COLOR);
	}
}

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 constructor directly by PowerMock. Example covers:

  1. Mocking of constructor
  2. Verifying of constructor call

Class under test:

public class CarFactoryPowerMock {
	public Car constructCar(String type, String color) {
		new Car(type, color);
		return new Car(type, color);
	}
}

Test:

/**
 * Demonstrates constructor mocking by PowerMock.
 * <p>
 * NOTE: Prepared in PowerMock annotation {@link PrepareForTest} should be class
 * where is constructor called
 */
@PrepareForTest(CarFactoryPowerMock.class)
public class CarFactoryPowerMockTest extends PowerMockTestCase {
	private static final String TESTING_TYPE = "Tatra";
	private static final String TESTING_COLOR = "Black";

	@Test
	public void testConstructCar() throws Exception {
		Car expectedCar = Mockito.mock(Car.class);
		PowerMockito.whenNew(Car.class)
				.withArguments(TESTING_TYPE, TESTING_COLOR)
				.thenReturn(expectedCar);

		// invoke testing method
		CarFactoryPowerMock carFactory = new CarFactoryPowerMock();
		Car actualCar = carFactory.constructCar(TESTING_TYPE, TESTING_COLOR);

		Assert.assertEquals(actualCar, expectedCar);
		// ... verify other logic in constructCar() method ...
		PowerMockito.verifyNew(Car.class, Mockito.times(2)).withArguments(
				TESTING_TYPE, TESTING_COLOR);
	}
}

Links

Source code can be downloaded from Github.

Other unusual mocking examples:

twittergoogle_plusrss

Mock private 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 private method

Refactoring considerations

Private method that is needed to be mocked can be in:

  • testing class (will call it TC)
  • direct dependency of testing class (will call is DDC)
  • class that is not direct dependency of testing module (will call it NDDC)

Re-factoring techniques to consider:

  • If the private method is in TC, it is a good sign that TC has low cohesion (has too many responsibilities) and logic behind private method should be extracted into separate class. After this refactoring, private method in TC becomes public in new dependency class. Than it is possible to mock it standard way.
  • If the private method is in DDC, concerns of TC and DDC modules are not separated properly. It means you are trying to test some logic from DDC in test for TC. Consider moving this logic to TC or to separate module. Private method than becomes public and can be mocked standard way.
  • If the private method is in NDDC, you are probably creating integration test instead of unit test. Unit test in theory should be testing module in isolation. That means to mock all direct dependencies (sometimes it’s easier to test with real objects when they are simple and independent enough). Consider:
    • Creation of unit test first. You can decide later if integration test is needed for group of modules you trying to test.
    • Find easier to mock boundaries for your integration test (you can find a clue in unit test for NDDC if exists)
    • Refactor NDDC according refactoring practises mentioned for TC and DDC above, update it’s unit test (also all tests affected by refactoring), and use created public method as boundary for your integration test.

Workaround using Mockito

This is my preferred technique when I need to mock private 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:

  • Changing private access modifier to default
  • Partially mock testing object by using spy

Mockito example covers:

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

Class under test:

public class Train {
	public int compose() {
		for (int idx = 0; idx < getWagonsCount(); idx++) {
			addWagon(0);
		}
		return getWagonsCount();
	}

	/**
	 * Access modifier was changed from private to default to enhance
	 * testability
	 */
	// private
	int getWagonsCount() {
		throw new UnsupportedOperationException("Fail if not mocked!");
	}

	/**
	 * Access modifier was changed from private to default to enhance
	 * testability
	 */
	// private
	void addWagon(int position) {
		throw new UnsupportedOperationException(
				"Fail if not mocked! [position=" + position + "]");
	}
}

Test:

@Test
public void testCompose() {
	Train train = new Train();
	Train trainSpy = Mockito.spy(train);

	//notice different Mockito syntax for spy   
	Mockito.doReturn(TESTING_WAGON_COUNT).when(trainSpy).getWagonsCount();
	Mockito.doNothing().when(trainSpy).addWagon(0);

	// invoke testing method
	int actualWagonCount = trainSpy.compose();

	Assert.assertEquals(actualWagonCount, TESTING_WAGON_COUNT);
	Mockito.verify(trainSpy, Mockito.times(TESTING_WAGON_COUNT))
			.addWagon(0);
}

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 private method directly by PowerMock. Example covers:

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

Class under test:

public class Truck {
	public double addLoad(Collection<Double> boxWeightsToAdd) {
		for (Double boxWeight : boxWeightsToAdd) {
			addBoxToLoad(boxWeight);
		}
		return getLoadWeight();
	}

	private double getLoadWeight() {
		throw new UnsupportedOperationException("Fail is not mocked!");
	}

	private void addBoxToLoad(double weight) {
		throw new UnsupportedOperationException("Fail is not mocked! [weight="
				+ weight + "]");
	}
}

Test:

@PrepareForTest(Truck.class)
public class TruckTest extends PowerMockTestCase {
	private static final double TESTING_LOAD_WEIGHT = 200;
	private static final double TESTING_BOX_WEIGHT = 100;

	@Test
	public void testTestingMethod() throws Exception {
		Truck truck = new Truck();
		Truck truckSpy = PowerMockito.spy(truck);

		PowerMockito.doReturn(TESTING_LOAD_WEIGHT).when(truckSpy,
				"getLoadWeight");
		PowerMockito.doNothing().when(truckSpy, "addBoxToLoad",
				TESTING_BOX_WEIGHT);

		// call testing method
		Collection<Double> boxesWeights = Arrays.asList(TESTING_BOX_WEIGHT,
				TESTING_BOX_WEIGHT);
		double actualLoad = truckSpy.addLoad(boxesWeights);

		Assert.assertEquals(actualLoad, TESTING_LOAD_WEIGHT);
		PowerMockito.verifyPrivate(truckSpy, Mockito.times(2)).invoke(
				"addBoxToLoad", TESTING_BOX_WEIGHT);
	}
}

Links

Source code can be downloaded from Github.

Other unusual mocking examples:

twittergoogle_plusrss