hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Yates <jesse.k.ya...@gmail.com>
Subject Re: testing, powermock, jmockit - from pow-wow
Date Mon, 24 Sep 2012 23:18:40 GMT
I did a couple of examples with powermock and jmockit to give people an
idea of some of the pain and goodness of the tools.

Here is a breakdown of what's going on in the attached files:

   1. Pom changes for powermock
      1. a simple set of changes to pull the right dependencies in
   2. whitebox access: demonstrates reflection helper utilities to access
   private methdos
      1. Means we can drop all the public methods and the "EXPOSED FOR
      TESTING" comments and just access via a clean api
   3. Private field access with annotations - annotate fields used in
   testing via reflection
   1. This is a tooling we use at SFDC to mark what fields are used via
      reflection so devs know when they are dealing with
reflection-tested stuff
      and to take care
      2. We can add a lot more tooling around this rather than the hackery
      that I use in the test to make accessing the right type easier
   4. Jmockit usage
      1. Here we are hooking up a mock TableHFileArchiveTracker. This is
      interesting because the object is created via a static method -
      TableHFileArchiveTracker.create(Configuration), which we can't
get at with
      Mockito.
      2. We can also do mockting of the rest of the private/public methods
      easily. See
      http://jmockit.googlecode.com/svn/trunk/www/tutorial/AnExample.html
      3. Problems:
      1. needs to be listed before junit (for loading hooks)
         2. needs a jvm with an Agent API (but we already require
         Sun/Oracle which has it)
         3. Loose eclipse debugging of mocked methods (but there is an eclipse
         plugin<http://marketplace.eclipse.org/content/jmockit-eclipse#.UGDp6FQWW6w>with
helpful utils)
         5. Attempting to spin up a mini-cluster test with powermock
      1. This doesn't actually work as there is a classloading clash
      2. HUGE pain to deal with (see all the ignores)


If you look closely (4) actually uses the powermock utils to test that we
are actually munging the state and using a custom mock object, since that
is far more lightweight and easy to use.

IMO using the Powermock Whitebox utilities (+ a little custom stuff to make
life easier) together with the jmockit tooling for getting at static/final
methods/classes is the right way to go for doing deeper testing without
radically refactoring existing code (or writing really obtuse code just for
easier testability).

I can refactor the patches above to just roll in powermock and jmockit
support into a patch HBASE-5456.


Thoughts?

Thanks,
Jesse
-------------------
Jesse Yates
@jesse_yates
jyates.github.com


On Fri, Sep 21, 2012 at 11:03 AM, Jesse Yates <jesse.k.yates@gmail.com>wrote:

>
> On Fri, Sep 21, 2012 at 9:49 AM, Ryan Rawson <ryanobjc@gmail.com> wrote:
>
>> I've used mockito a few times, and it's great... but it can make your
>> tests very brittle.  It can also be hard to successfully use if the
>> code is complex.  For example I had a class that took an HBaseAdmin,
>> and i mocked out the few calls it used.  Then when I needed to access
>> Configuration, things went downhill fast.  I ended up abandoning
>> easymock even.
>>
>>
> Interesting... I was recently mocking out some stuff with HBaseAdmin and
> didn't have that much trouble (except for HBASE-6495 which is now fixed).
>
>
>> The issue ultimately stems from not writing your code in a certain way
>> with a minimal of easy to mock external interfaces.
>
>
> Nice sentiment but a non-trivial ask with legacy code :) Part of the
> problem here is that EasyMock/Mockito don't hack it when they aren't
> designed for testing.
>
>
>>  When this isn't
>> true, then easymock does nothing for you.  It can save your bacon if
>> you are trying to unit test something deep though.
>>
>> The other question I guess is integration testing... there is no
>> specific good reason why everything is done in 1 jvm, except 'because
>> we can'.
>
>
> It helps provides isolation between tests so we can be sure of which tests
> are actually failing.
>
>
>> a longer lived 'minicluster' could amortize the cost of
>> running one.
>>
>
> Looked into the long running minicluster about 8 months ago -  it
> generally wouldn't help all that much. A lot of the minicluster tests get
> into the internals and muck about with things to test error scenarios. The
> work it would take to have a shared minicluster for tests that just need to
> run on a cluster. That said, a lot of those kinds of tests are moving to
> the hbase-it package so they can run on a minicluster or a real cluster.
>
>
>>
>> -ryan
>>
>> On Fri, Sep 21, 2012 at 9:06 AM, Rogerio <rliesenfeld@gmail.com> wrote:
>> > lars hofhansl <lhofhansl@...> writes:
>> >
>> >> > 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*).
>> >>
>> >
>> > I think you are imagining a problem that does not exist. JMockit users
>> can debug
>> > Java code just fine...
>> >
>> >
>>
>
>

Mime
View raw message