-Re: testing, powermock, jmockit - from pow-wow
lars hofhansl 2012-09-15, 04:13
Using Powermock for its reflection library sounds great. I'd refrain from using its classloader, that is just asking for trouble.
> To get the low-level access we could instead use jmockit at the cost of dealing with code-weaving.
As we had discussed, this scares me :).
I do not want to have to debug some test code that was weaved (i.e. has no matching source code lying around *anywhere*).
Generally I think code should be designed to be unittestable. Each (set of) class(es) should be able to stand alone, enough to be unittested, then only a few bigger bigger functional tests are needed to test things end-to-end... I know that's pipe-dream. I'm also asking for every committer to be given a pony, btw.
Mocking is the next best option.
Thanks for taking this on!
From: Jesse Yates <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Friday, September 14, 2012 7:16 PM
Subject: testing, powermock, jmockit - from pow-wow
TL;DR powermock is really hard (and ugly) to get working for the
class-loading abilities, but has a really nice reflection library we can
leverage. To get the low-level access we could instead use jmockit at the
cost of dealing with code-weaving.
At the pow-wow there was also some discussion of ways in which we can
improve the testing infrastructure. Options toss around were things like
improving the testing util, fixing classes to make them more testable, and
The first two are definitely the right way to go, but can be pretty hard to
do (problem with all legacy code) and often times can lead to awkward code
to facilitate testing. Here, PowerMock is great - it lets you get into the
internals more easily.
That said, I've started working on HBASE-5456 (Introduce PowerMock into our
unit tests to reduce unnecessary method exposure) and its a hairy mess.
Powermock's whole functionality is based on using its own classloader.
However, because of all the reflection that HBase and Hadoop does
(particularly Hadoop here), we end up having to do a ton of ignore
statements for classes/packages that PowerMock shouldn't load. I hacked on
it for a bit and still couldn't get a mini-cluster up and running :-/
Even given that pain we can get a lot of use from the reflection utilities
- this allows you to replace existing objects with mocks, access private
methods (no more 'exposed for testing methods'). The powermock jars amount
to about 100K - small overhead for a lot the helper methods. See
To resolve the cases where the powermock class-loading would be useful
(e.g. catching object creation to use your own mock, rather than using
factories or DI everywhere) we could use jmockit. Jmockit does the same
basic stuff as powermock (minus the nice reflection library), but it does
it through run-time code weaving for tests through the java agent
This will give us really fine grained access to the code under test without
having to do a lot of funky rewrites. However, code-weaving comes at the
cost of loosing debugger usage as the code-weaving messes with the
bytecode. I'd argue that its a small price to pay for getting highly
controllable tests, *as long as we don't go overboard with the
weaving.*Yes, when we start doing too much test weaving it can become
it can be really useful for many situations without having to write
What do ya'll think?