Once upon a time you got sick of writing code and having it fail when you ran, or someone else did, and you learned to unit test your code.
You read the JUnit docs, and wrote tests for those classes which contained discrete, self-contained code. And quickly realised that the world doesn’t work like that.
Code relies on other code. Often very complex code. And you discovered dependency injection. You abstracted out the collaborating class, and injected it in to the code. Great!
Now you could use stubs – code which always behaves in a certain way – as part of your test, and discretely use them to test the top level code. Awesome! For about two weeks.
The stubs became too inflexible, and every time you changed the interface of the class being stubbed, you had to change the stub too. Not only that, having the stubbed code behave the same way every time was too inflexible. What if you need to test how the top-level code reacts when its collaborators throw errors?
So you looked on the net and you learned about mock objects. It was like getting into a hot bath. Now you could dynamically define the behaviour of collaborating classes in every test. You could test exception handling! Excellent! Until once again, it wasn’t.
Because the world doesn’t work like that. Your code style develops. You want to use other patterns, and behaviours, that don’t fit well with the idea of injection, and which are a code-level implementation detail. Sometimes you just want to instantiate a class and use it. And not have to test it along with the code that uses it. Maybe it’s builders. Maybe it’s a stream that you want to write to. Conversely, you don’t want to litter your Spring config with objects of a tiny ganularity just for the purposes of testing. And you find that your testing tools aren’t enough. Not only that, they are now driving the design of your code.
What if you could write code at the level of abstraction that makes sense to you? Static helper methods? Builders? Package private classes that get instantiated from inside your code? What if you want to wire the objects in your application at a granularity that makes sense?
“Surely, you must be smoking!” I hear you say. “That is a pipe dream reserved for dynamic language programmers, not us grunting around at the coalface in Java.” Well, actually, no. The latest generation of unit testing tools allow you to do just that! With Java!
JMockit is one of the latest toolkits in the evolutionary chain of mocking tools. It depends on the instrumentation APIs in Java 6 to enable behaviour that was previously unattainable. One of the prerequisites is that you are using the latest 1.6 JDK for your code, but if you are – rock and roll. Let me demonstrate:
Let’s say that you are writing an application that blatantly violates the trademarks of MTV’s favourite show and tricks out rubbish cars. Here’s your main code:
package demo;
public class PimpingService {
private CarDao carDao;
public void setCarDao(CarDao tradeDao) {
this.carDao = tradeDao;
}
/**
* Loads a car and pimps it, saving it and returning.
* representative of a lot of code out in the wild.
*
* @param carId The primary key of the car to load.
* @return The pimped ride.
*/
public Car pimpRide(Long carId) {
Car unpimpedCar = carDao.findCar(carId);
Car pimpedCar = PaintShop.resprayWithFlames(unpimpedCar);
if (pimpedCar.getValue() > 100000) {
ElectronicsWizard wizard = new ElectronicsWizard(24);
pimpedCar = wizard.makeFullySick(pimpedCar);
}
try {
carDao.save(pimpedCar);
} catch (IllegalStateException isx) {
// roll back our changes
pimpedCar = unpimpedCar;
}
return pimpedCar;
}
}
You’ve got some pretty interesting usage patterns here:
- a dependency injected DAO
- use of static methods
- object instantiation
The first is pretty straightforward to mock up, but the others, not so much.
Let’s take a look at the other classes:
package demo;
public final class Car {
private final Double value;
public Car(Double value) {
this.value = value;
}
public Double getValue() {
return value;
}
}
package demo;
public class CarDao {
/**
* Finds a car by its primary key.
* @param carId The primary key.
* @return A car if found, or null.
*/
public Car findCar(Long carId) {
// normally there'd be some kind of jdbc thing here
return new Car(100000d);
}
/**
* Saves a car.
* @param car The car.
*/
public void save(Car car) {
// ...
}
}
package demo;
public class PaintShop {
/**
* Resprays a car, increasing its value.
* @param car The car.
* @return A resprayed version of the car.
*/
public final static Car resprayWithFlames(Car car) {
Car resprayedCar = new Car(car.getValue() * 2);
return resprayedCar;
}
}
package demo;
public class ElectronicsWizard {
private int multiplier;
public ElectronicsWizard(int multiplier) {
this.multiplier = multiplier;
}
/**
* Makes a car fully sick.
* @param car The car to make fully sick.
* @return A fully sick car.
*/
public Car makeFullySick(Car car) {
return new Car(car.getValue() * multiplier);
}
}
So, as we run the code, things happen. We first load the car, and then we keep changing its value depending on what operations we run on it.
Let’s exercise it using JUnit and JMockit. This code uses JUnit 4 and JMockit 0.98.
package demo;
import mockit.Expectations;
import mockit.Mocked;
import mockit.integration.junit4.JMockit;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import static org.junit.Assert.assertSame;
@RunWith(JMockit.class)
public class TradeServiceTest {
@Mocked
private CarDao mockCarDao;
@Mocked
private ElectronicsWizard mockWizard;
@Mocked
private final PaintShop unusedMockPaintShop = null;
private PimpingService pimpingService;
@Before
public void setUp() {
pimpingService = new PimpingService();
pimpingService.setCarDao(mockCarDao);
}
/**
* Checks that happy path to pimping cars.
*/
@Test
public void testPimpRide() {
final Long carId = 1L; // this is the id that we'll look up
// the ride we'll expect to get back from the process
final Car fullySickCar = new Car(300000.0);
new Expectations() {
{ // static block
// set an expectation on this mock that it will be invoked with
// a car id
mockCarDao.findCar(withEqual(carId));
Car foundCar = new Car(100000.0);
returns(foundCar); // return value from last mock call
// this static method will be called next
PaintShop.resprayWithFlames(withSameInstance(foundCar));
Car resprayedCar = new Car(200000.0);
returns(resprayedCar); // set its return value
new ElectronicsWizard(24);
returns(mockWizard);
mockWizard.makeFullySick(withSameInstance(resprayedCar));
returns(fullySickCar);
// we're done
mockCarDao.save(withSameInstance(fullySickCar));
}
};
// all that's left is to invoke our service and see what happens
Car resprayedCar = pimpingService.pimpRide(carId);
assertSame(fullySickCar, resprayedCar);
}
}
So what’s going on here?
- We import a few JMockit classes (line 11) to help us with the testing. Because of the way that JMockit operates, there are bits and pieces that are required to integrate the toolkit with the testing framework being used. Here, we import the JUnit version.
- You need to create placeholders (lines 14-19) for each of the classes that you will be mocking, regardless of whether you want to instantiate them, such as in the case of our unusedMockPaintShop, on which we will just be calling static methods.
- You define mock objects behaviour in an Expectations block. This makes use of a syntax similar to JMock, where all your code is defined in a static block (line 38). If you are used to EasyMock, you’ll immediately notice the change in style. You use static methods of the Expectations class immediately after the expected method calls to define how the mock object will behave. Line 44’s returns(foundCar) is an instruction for the mockCarDao used on line 42.
The rest pretty much looks like a standard unit test. What about some different behaviour from the instantiated class?
/**
* Checks that the electronics wizard won't get called in if the paintshop gives us a
* car with a small value amount.
*/
@Test
public void testPimpRideElectronicsWizardNotCalled() {
final Long carId = 1L;
// the car we'll expect to get back - look at the new value
final Car resprayedCar = new Car(50000.0);
new Expectations() {
{
mockCarDao.findCar(withEqual(carId));
Car foundCar = new Car(100000.0);
returns(foundCar);
PaintShop.resprayWithFlames(withSameInstance(foundCar));
returns(resprayedCar);
// its return value is < 100,000 so no wizard here
// if the wizard was invoked, you'd get an error:
// Unexpected invocation of: demo.ElectronicsWizard#ElectronicsWizard(int)
// it's @Mocked, remember?
mockCarDao.save(withSameInstance(resprayedCar));
}
};
Car tradeReturnedFromService = pimpingService.pimpRide(carId);
assertSame(resprayedCar, tradeReturnedFromService);
}
That’s all well and good. But what about testing how our code will handle exceptions?
/**
* Checks that no wizard work will be done if respraying gives us a
* car with a small value amount.
*/
@Test
public void testPimpRideElectronicsWizardNotCalledSavingBreaks() {
final Long carId = 1L;
final Car foundCar = new Car(100000.0);
new Expectations() {
{
mockCarDao.findCar(withEqual(carId));
returns(foundCar);
PaintShop.resprayWithFlames(withSameInstance(foundCar));
Car resprayedCar = new Car(50000.0);
returns(resprayedCar);
mockCarDao.save(withSameInstance(resprayedCar));
// dao throws a humorous antipodean complaint here
IllegalStateException isx = new IllegalStateException("Ooh bugger");
throwsException(isx);
}
};
Car tradeReturnedFromService = pimpingService.pimpRide(carId);
// the service should have just returned the car it found
assertSame(foundCar, tradeReturnedFromService);
}
That’s nowhere near what you can do with JMockit, but it should give you a good taster. Code that was previously untestable, can now be dealt with as easily as a straightforward class with injected dependencies. Go forth and code in whatever way makes sense to you, DI or not, content in the knowledge that it’s all good and testable.
View Jakub Korab's profile
