Even if you don’t like it, your job sometimes requires you to maintain legacy applications. It happened to me (fortunately rarely), and the first thing I look for before writing as much as a single character in a legacy codebase is a unit testing harness. Most of the time, I tend to focus on the code coverage of the part of the application I need to change, and try to improve it as much as possible, even in the total lack of unit tests.
Real trouble happens when design isn’t state-of-the-art. Unit testing requires mocking, which is only good when dependency injection (as well as initialization methods) makes classes unit-testable: this isn’t the case with some legacy applications, where there is a mess of private and static methods or initialization code in constructors, not to mention static blocks.
For example, consider the following example:
public class ExampleUtils {
public static void doSomethingUseful() { ... }
}
public class CallingCode {
public void codeThatShouldBeTestedInIsolation() {
ExampleUtils.doSomethingUseful();
...
}
}It’s impossible to properly unit test the codeThatShouldBeTestedInIsolation() method since it has a dependency on another unmockable static method of another class.
Of course, there are proven techniques to overcome this obstacle.
One such technique would be to create a "proxy" class that would wrap the call to the static method and inject this class in the calling class like so:
public class UsefulProxy {
public void doSomethingUsefulByProxy() {
ExampleUtils.doSomethingUseful();
}
}
public class CallingCodeImproved {
private UsefulProxy proxy;
public void codeThatShouldBeTestedInIsolation() {
proxy.doSomethingUSeful();
...
}
}Now I can inject a mock UsefulProxy and finally test my method in isolation.
There are several drawbacks to ponder, though:
- The produced code hasn’t provided tests, only a way to make tests possible.
- While writing this little workaround, you didn’t produce any tests. At this point, you achieved nothing.
- You changed code before testing and took the risk of breaking behavior! Granted, the example doesn’t imply any complexity but such is not always the case in real life applications.
- You made the code more testable, but only with an additional layer of complexity.
For all these reasons, I would recommend this approach only as a last resort. Even worse, there are designs that are completely closed to simple refactoring, such as the following example which displays a static initializer:
public class ClassWithStaticInitializer {
static { ... }
}As soon as the ClassWithStaticInitializer class is loaded by the class loader, the static block will be executed, for good or ill (in the light of unit testing, it probably will be the latter).
My mock framework of choice is Mockito. Its designers made sure features such as static method mocking weren’t available and I thank them for that. It means that if I cannot use Mockito, it’s a design smell. Unfortunately, as we’ve seen previously, tackling legacy code may require such features. That’s when enters PowerMock (and only then - using PowerMock in a standard development process is also a sure sign the design is fishy).
With PowerMock, you can leave the initial code untouched and still test to begin changing the code with confidence. Here’s the test code for the first legacy snippet, using Mockito and TestNG:
@PrepareForTest(ExampleUtils.class)
public class CallingCodeTest {
private CallingCode callingCode;
@BeforeMethod
protected void setUp() {
mockStatic(ExampleUtils.class);
callingCode = new CallingCode();
}
@ObjectFactory
public IObjectFactory getObjectFactory() {
return new PowerMockObjectFactory();
}
@Test
public void callingMethodShouldntRaiseException() {
callingCode.codeThatShouldBeTestedInIsolation();
assertEquals(getInternalState(callingCode, "i"), 1);
}
}There isn’t much to do, namely:
- Annotate test classes (or individual test methods) with
@PrepareForTest, which references classes or whole packages. This tells PowerMock to allow for byte-code manipulation of those classes, the effective instruction being done in the following step. - Mock the desired methods with the available palette of
mockXXX()methods. - Provide the object factory in a method that returns
IObjectFactoryand annotated with@ObjectFactory.
Also note that with the help of the Whitebox class we can access the class internal state (i.e. private variables).
Even though this is bad, the alternative - taking chance with the legacy code without test harness is worse: remember our goal is to lessen the chance to introduce new bugs.
Features list of PowerMock is available here for Mockito. Note that suppressing static blocks is not possible with TestNG right now.
You can find the sources for this article here in Maven format.