PowerMock examples and why better not to use them

Last Updated on by

Post summary: In this post I have summarised all PowerMock examples I’ve given so far. More important I will try to give some justification why I think necessity to use PowerMock is considered an indicator for a bad code design.

All code examples are available in GitHub java-samples/junit repository.


PowerMock is a framework that extends other mock libraries giving them more powerful capabilities. PowerMock uses a custom classloader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods, removal of static initialisers and more.

PowerMock series

So far in my blog I have written a lot for PowerMock. Even more that I have written for Mockito which actually deserves better attention. Post from PowerMock series are:

Why to avoid PowerMock

I have worked on a project where PowerMock was not needed at all. We had 91.6% code coverage only with Mockito. Initially it was 85% but when we utilised PITest we increased the code coverage. See more on PITest in Mutation testing for Java with PITest post. I also have worked on a old product where without PowerMock you cannot do decent unit testing. PowerMock was a must in order to achieve our goal of 80% code coverage. I can easily compare those two projects. Old one had large classes with lots of private methods and used lots of static methods. It was really hard to maintain that code. In this post I’m not going to talk about SOLID because I do not consider myself total expert on the subject. There are lots of discussions over internet about pros and cons of static methods so everyone can decide personally. For me I’ve come to a conclusion that necessity of using PowerMock in a project is a indicator for bad code design. In later projects PowerMock is not used at all. If something cannot be unit tested with Mockito then class is refactored.

How to avoid PowerMock

PowerMock features described here are related to static methods, public methods and creating new objects.

Mock or verify static methods

I’m not saying don’t use static methods, but they should be deterministic and not very complex. Not being able to verify static method was called is a little pain but most important is input and output of your method under test, what internal call it is doing is not that important.

Mock or call private methods

Private methods are not supposed to be tested as all. It is like they do not exist. If class is complex enough so you have to call private methods or to test individually private methods then this class might be good to be split up.

Mock new object creation

Instead of creating the object in the class use dependency injection to provide it to the class from outside either via constructor or via setter. This was you can very easily test this class by injecting a mock.


This is very controversial post. On one hand I describe how to use PowerMock and what features it has on the other had I state that you’d better not use it. PowerMock is extremely powerful and can do almost anything you need in your testing, but for me necessity of using PowerMock is an indicator of bad code design.

If you find this post useful, please share it to reach more people. Sharing is caring!
Share on FacebookShare on LinkedInTweet about this on TwitterShare on Google+Email this to someone
Category: Java, Unit testing | Tags: