PowerMock + Mockito VS Mockito alone

Question

Can anyone please summarize, what exactly features gives you adding PowerMock on top of the Mockito?

So far I've found these:

• mock static, final and private methods
• remove static initializers
• allow mocking without dependency injection - this one isn't clear to me. Can you elaborate?

Does it add anything else? Can you please sum up in several lines?

And do I need to sacrifice something when using PowerMock?

Solution 1

I don't know of other benefits offhand, but I want to address 2 of your sub-questions (and this is way too long for a comment):

allow mocking without dependency injection - this one isn't clear to me. Can you elaborate?

I think this came from the Motivation wiki page where they describe a way of refactoring code to not invoke static methods to make it testable. For a concrete example of what I think they're getting at, let's say you have this code and you want to test the method mocking the behaviour of the static method, without using powermock:

public class MyClass {
     public void doGetString() {
         ...
         OtherClass.getString(); //It's complex and scary and needs mocking!
         ...
     }
}

One solution, would be to pull the static invocation into its own object, then inject an object that can be mocked come test time. For example, without using other frameworks, this could look like:

public class MyClass {
     public static class StringGetter {
         public getString() {
             return OtherClass.getString();                 
         }
     }

     private final StringGetter getter;

     //Existing Constructor
     public MyClass() {
         this(new StringGetter());
     }

     //DI Constructor
     MyClass(StringGetter getter) {
         this.getter = getter;
     }

     public void doGetString() {
         ...
         getter.getString();
         ...
     }
}

I've seperated the behaviour of my method from the behaviour of the static invocation, and can use the DI constructor to inject mocks easily at test time. Of course with powermock I could just mock the static method in place, and run with it.

And do I need to sacrifice something when using PowerMock?

Physically no, but I'd say philosophically yes :). The below are my opinions, and I try to give good reasons behind them, but of course they are opinions so take them with a grain of salt:

The potentially scary thing that is happening with PowerMock is that in order to accomplish the feats of mocking private and static methods, they are using a custom class loader (which shouldn't be present at runtime in production) and changing the bytecode of your classes. Arguably, this should not matter with the vast majority of classes most of the time, but if you think about it, if the bytecode has changed, and certain side effects are no longer present, you're effectively testing different Classes albiet based upon your existing Classes. Yes this is a very academic argument.

You can somewhat mitigate this first argument by having good comprehensive integration and higher level tests that don't use PowerMock. In this way you can be more confident in the behaviours of your objects even if your unit tests are using PowerMock.

The other argument I have against PowerMock, is that it could almost too easily become a crutch. I agree that PowerMock can help with testing code that uses legacy code and other code that you do not have control over. However I would argue that when you have control over the classes that you need to mock, you should avoid its use. If you write a class with a private method or static method that you need to explicitly mock in order to test other methods, my gut instinct would say that this method may be doing too much and should be refactored and broken up. Having PowerMock already available in a project, you may be tempted to just mock it and move on, which would mitigate the pain that should encourage you to refactor the same. Yes there are sometimes due to various technical and non-technical constraints this is not possible, but it's good to solve pain points instead of avoid them :)

Solution 2

PowerMock is an extension to Mockito that allows mocking of static methods, constructors, final classes and methods, private methods, removal of static initializers and more.

Solution 3

Another feature of the Powermock mockito extension is that it supports mocking and stubbing of equals and hashcode.

As with all powermock features to be used with care, but adding (value-based) equality for specific results can be helpful.

Solution 4

One more feature of PowerMock is that we can mock construction of new objects in a method. It is helpful when we cannot change the code of the method to be tested.

Solution 5

For mocking final class we can use org.mockito.plugins.MockMaker. What you would need to do is

1. Create a folder in your test/resource folder with namemockito-extensions.
2. Create a file under it with the name org.mockito.plugins.MockMaker.
3. In that file have just one line mock-maker-inline

This will not require you to do add any new library and hence save some runtime.

View more solutions

Comments

[Sled]

I would like to summarise the parent's caution about using PowerMock to a tl;dr version: "refactoring, when possible/allowed is preferrable; having PowerMock available may dissuade refactoring"

[Rogério]

"...you're effectively testing different Classes albeit based upon your existing Classes"->This also applies to the mock subclasses created through CGLIB, which itself uses a custom class loader; the tested class is not directly modified, but calls to mocked methods must first go through the overriding method, whose bytecode was created dynamically. So, this argument is really weak. Regarding the "crutch" argument, I think you miss the other side of the coin: having roadblocks against the use of final, new and static means you need to sacrifice certain useful design choices.

[Charlie]

1) It sounds like you are assuming that I'm extending the class under test in order to test it? While this is indeed a feature of Mockito, I would argue that this case also wreaks of code smell (If I'm mocking parts of my class to test other parts, my separation of concerns isn't likely very good). Now as far as Mocked objects that I provide to my code under test, I could care less about how they work so long as they are stable for my tests, my class under test should be as close to production as possible.

[Charlie]

2) I still stand by the crutch argument. There is nothing preventing me from using final, new, or static... but it is my Opinion that code in such methods shouldn't require mocking if I choose to use them. If they are that complex or riddled with side effects, I probably should think about encapsulating into other objects so I could inject mocks at test time or when implementations change. (Not to mention with DI frameworks like Guice "@Inject is the new new" :D)