Lives in the UK. Likes blogging, cycling and eating lemon drizzle cake. Roger is a DZone MVB and is not an employee of DZone and has posted 142 posts at DZone. You can read more from them at their website. View Full User Profile

Why Use PowerMock to Mock Private Methods?

  • submit to reddit
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) {

    return getStatsFromCache();

   * Calculate some statistic taking a long time.
  private boolean crunchNumbers() throws InterruptedException {

    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:
public class PrivateMethodTest {

  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);

    final long startTime = System.currentTimeMillis();
    String result = instance.calculateStats();
    final long duration = System.currentTimeMillis() - startTime;

    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.



Published at DZone with permission of Roger Hughes, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Witold Szczerba replied on Fri, 2011/10/28 - 3:46pm

I am sorry, but I must repeat myself: testing how objects work internally is a waste of time, this is exactly the same case as here:

Roger Hughes replied on Sat, 2011/10/29 - 5:12am

See my last reply to your comment - again I quite agree, that mocking private methods isn't too helpful; hence take a look at the title "Why Use PowerMock to Mock Private Methods?" - I thought really hard and long and could only come up with one possible reason to do this i.e. if your build time exceeded acceptable limits and you wanted to reduce it to comply with Agile's 10 Minute Build Rule - a remote possibility edge case.

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

Nicolai Cebanov replied on Wed, 2013/11/13 - 1:00am

That's interesting, but this approach doesn't work for private methods with void return type.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.