Why Use PowerMock to Mock Private Methods?
So far I’ve written a couple of blogs on PowerMock covering some of what
I think are its most useful features. Today’s blog takes a look at
PowerMock’s ability to mock private methods. At first this struck me as a
pretty useless idea. The PowerMock documentation says that you can use
it to mock private methods that are called many times during your build
process so that you only test them once. My first reaction was does it
matter whether or not you execute a piece of code once or a thousand
times during a set of unit tests? Usually the answer will be ‘no’ and
this feature will be pretty superfluous. However, there is a scenario
where is come come in very handy...
Suppose you have a private method that does something really time consuming, for example calculates some statistics by crunching some numbers and it took, for example, 1 minute to work out each result. Calling this method many times during unit testing would seriously increase your build time, breaking Agile’s Ten Minute Build Rule, possibly to the point where building continuously is impractical.
Today’s code sample demonstrates this scenario. The contrived idea is that we’ve written a class called GameStatistics to calculate some statistics for a sports game. This class can cache its statistics only calculating them if they aren’t available, but calculating them takes at least a minute using the private crunchNumbers(...) method. Tests have already been written for the calculation of these stats and we’re happy they work. However, other test scenarios repeatedly call crunchNumbers(...) and it’s seriously affecting the build time. This is where PowerMock’s private method mocking comes in to play...
In the sample code above the crunchNumbers(...) method mimics some kind of long winded calculation by simply sleeping for 60 seconds. This method is called using the public calculateStats(...) method and that's tested using the JUnit code below:
This is a straight forward PowerMock assisted JUnit test. It uses the usual RunWith(PowerMockRunner.class and a PrepareForTest() call that uses GameStatistics as an argument.
The lines of code that are of interest are:
The second line of interest is the call to expectPrivate, which sets up the test expectations in the usual way.
Running this test on my machine took 20mS instead of a minute thus significantly reducing our scenario's build time and getting the build process back on track.
Suppose you have a private method that does something really time consuming, for example calculates some statistics by crunching some numbers and it took, for example, 1 minute to work out each result. Calling this method many times during unit testing would seriously increase your build time, breaking Agile’s Ten Minute Build Rule, possibly to the point where building continuously is impractical.
Today’s code sample demonstrates this scenario. The contrived idea is that we’ve written a class called GameStatistics to calculate some statistics for a sports game. This class can cache its statistics only calculating them if they aren’t available, but calculating them takes at least a minute using the private crunchNumbers(...) method. Tests have already been written for the calculation of these stats and we’re happy they work. However, other test scenarios repeatedly call crunchNumbers(...) and it’s seriously affecting the build time. This is where PowerMock’s private method mocking comes in to play...
public class GameStatistics {
private final boolean noStatsAvailable = true;
/**
* A public method
*
* @throws InterruptedException
*/
public String calculateStats() throws InterruptedException {
if (noStatsAvailable) {
crunchNumbers();
}
return getStatsFromCache();
}
/**
* Calculate some statistic taking a long time.
*/
private boolean crunchNumbers() throws InterruptedException {
TimeUnit.SECONDS.sleep(60);
return true;
}
private String getStatsFromCache() {
return "100%";
}
}In the sample code above the crunchNumbers(...) method mimics some kind of long winded calculation by simply sleeping for 60 seconds. This method is called using the public calculateStats(...) method and that's tested using the JUnit code below:
@RunWith(PowerMockRunner.class)
@PrepareForTest(GameStatistics.class)
public class PrivateMethodTest {
@Test
public final void testMockPrivateMethod() throws Exception {
final String methodToTest = "crunchNumbers";
final String expected = "100%";
// create a partial mock that can mock out one method */
GameStatistics instance = createPartialMock(GameStatistics.class, methodToTest);
expectPrivate(instance, methodToTest).andReturn(true);
replay(instance);
final long startTime = System.currentTimeMillis();
String result = instance.calculateStats();
final long duration = System.currentTimeMillis() - startTime;
verify(instance);
assertEquals(expected, result);
System.out.println("Time to run test: " + duration + "mS");
}
}
This is a straight forward PowerMock assisted JUnit test. It uses the usual RunWith(PowerMockRunner.class and a PrepareForTest() call that uses GameStatistics as an argument.
The lines of code that are of interest are:
GameStatistics instance = createPartialMock(GameStatistics.class, methodToTest); expectPrivate(instance, methodToTest).andReturn(true);The first of these uses PowerMock’s createPartialMock(...) method to mock a specified part of a class, which in this case is the crunchNumbers(...) method.
The second line of interest is the call to expectPrivate, which sets up the test expectations in the usual way.
Running this test on my machine took 20mS instead of a minute thus significantly reducing our scenario's build time and getting the build process back on track.
From http://www.captaindebug.com/2011/10/why-use-powermock-to-mock-private.html




Comments
Witold Szczerba replied on Fri, 2011/10/28 - 3:46pm
http://java.dzone.com/articles/testing-objects-internal-state#comment-58223
Roger Hughes replied on Sat, 2011/10/29 - 5:12am
On the whole I agree that there's no substitute for good OO and that tests should test and object's behaviour, not state or internals, but I think that you should be a bit more pragmatic, we don't work in a perfect world, not everyone does good OO and you often have to work on (other people's) code that's less than optimal. Code that's old, creaky, without any unit tests and suffering from a multitude of anti-patterns. In this case a bit a pragmatism goes a long way. If there's a tool or technique that works and will help you to meet your old creaky code's deadlines then why not use it. I kind of think that it's better to have some tests - however imperfect they are - than no tests at all. Perhaps you don't live in such a world and can write all you code from scratch. If so then lucky you!
Finally, I've no connection with PowerMock - I merely exploring a few of its features, figuring out which would be useful and which weren't and trying to keep an open mind. I've never used mocking of private methods or internal state testing, but have used mocking of static objects on some old sub-optimal legacy code, which did prove useful.
Witold Szczerba replied on Sat, 2011/10/29 - 5:03pm
You are right, sometimes it can be usefull when working with not well written code. The only thing is that I would start the article with such an explenation as you just wrote in response to my post. The truth is that many programmers don't know it. I was one of them at the beginning. I was trying to write unit tests and they were causing more troubles than they were worth. I wanted to convince my coleagues that tests are important, but I could not convince myself in the first place. Only after realising what does the OOP mean in practice, one can actually start writing tests or even practice a test-driven-development (or behavior-driven-development, but for me the better name would be use-case-test-driven-development, hehe).