Reviewing PowerMock's Features

When you write a blog, you get a feel for those subjects that are contentious and those that aren’t and one of the most contentious subjects seems to be the area of unit test techniques: are you a mockist or a classist? Can you test internal state or private methods? Should you just test behaviour? Just out of curiosity, I recently took a look at Powermock, software with which I have no relationship, and I wrote four simple ‘how to’ blogs on some of its features. The blogs were:

1. Using PowerMock to Mock Static Methods
2. Using PowerMock to Mock Constructors
3. Why Use PowerMock to Mock Private Methods?
4. Testing an Object's Internal State with PowerMock

One of the things I didn’t do was to sum up how useful I thought each of the features were, which led to some constructive criticism, which I broadly agreed with before the authors made their first keystrokes.

So, how useful are these features? Let’s take a quick look.

Firstly, mocking static methods. This, I think is Powermock’s best feature, if you’re of the opinion that you should be mocking messages or roles between objects and have come unstuck because the mocking framework you were using wouldn’t allow you to mock static methods then use this. This is a feature that I’ve found useful on a number of occasions.

Next mocking constructors, and I guess that the first question to ask is why would you need to do this? The answer should be that you don’t, all your external dependencies are injected and you’ve only used ‘new’ for objects that are internal to your code. You may imagine that this feature is redundant, BUT... what if the code you’re working on is an old and creaky plate of spaghetti? The authors have never heard of DI and somewhere right in the middle of it all is a line of code that does something like: new DataAccessObject() - i.e. an object accesses an external resource, something that’s a very good candidate for a mock object. In this case, mocking ‘new’ comes in handy as you can now mock dependency injection,

My next blog was on mocking private methods and I had to really struggle to come up with a scenario where this would be useful, with only Agile’s Ten Miniute Build Rule coming to the rescue as it may help you to reduce your build time... hmmm.

My final Powermock blog was on testing an object’s internal state, something which you should never really have to do, for all kinds of reasons though mainly because you end up with brittle tests that need updating every time you change your code. From this you could conclude that this tool/technique is at best redundant... or is it? Perhaps a little pragmatism could come in useful as 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. 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. All of which leads me to conclude that there are perhaps sub optimal testing techniques that can be applied to sub optimal code.

And finally, if it’s only me that lives in such an imperfect world then let me know and maybe I should look for another job.