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...

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.