hbase test library

[Patrick Angeles <pa...@gmail.com>]

Hey all,

It would be a considerable help to the developer community if there were a
set of mock classes for HTable and friends to help with unit testing. Having
MiniHBaseCluster available as a public API would also be extremely useful
for integration testing and RAD (used in conjunction with, say, embedded
Jetty for HBase-backed web apps).

The mocks do not yet exist (or is available from places external to the
project) and MiniHBaseCluster exists in the HBase test classpath but not
packaged for public use. I'd like the devs to consider another split of the
project such that there is an hbase-test module that can be included in the
test classpaths of client projects. There's been talk about a separate
hbase-client module for just the client API, this effort could be done in
conjunction with that one.

Cheers,

- P

Re: hbase test library

[Stack <st...@duboce.net>]

Hey Chief:

See in the below.

On Fri, Apr 29, 2011 at 6:09 AM, Patrick Angeles
<pa...@gmail.com> wrote:
> It would be a considerable help to the developer community if there were a
> set of mock classes for HTable and friends to help with unit testing. Having
> MiniHBaseCluster available as a public API would also be extremely useful
> for integration testing and RAD (used in conjunction with, say, embedded
> Jetty for HBase-backed web apps).
>

I like the way you are thinking Patrick but let me make sure I'm
following along.

So, these mocks implement the HTableInterface?  Or?

And tell us more what you mean by MiniHBaseCluster as a public API?


> The mocks do not yet exist (or is available from places external to the
> project) and MiniHBaseCluster exists in the HBase test classpath but not
> packaged for public use. I'd like the devs to consider another split of the
> project such that there is an hbase-test module that can be included in the
> test classpaths of client projects. There's been talk about a separate
> hbase-client module for just the client API, this effort could be done in
> conjunction with that one.
>

So, we publish hbase-*.jar one of which is the test jar up in apache's
maven repo already.  You want more than that?

Security is probably going to be the forcer that brings on maven
submodules in the hbase project so we can build build secure and
insecure hbase switching in secure and insecure hadoop dependencies as
appropriate.   I'd imagine the project submoduling would happen post
0.92 (Is there an argument to do it ahead of 0.92?).  So, including
your test module, its looking like we'll have at least: hbase-core,
hbase-secure, hbase-client, and hbase-test.  Any others?

Thanks Patrick,
St.Ack

Re: hbase test library

[Stack <st...@duboce.net>]

On Fri, Apr 29, 2011 at 12:11 PM, Joe Pallas <jo...@oracle.com> wrote:
> I will say that startup time for the minicluster is pretty bad for unit testing.  Maybe what the original request was really asking for is what Fowler calls "fakes" <http://martinfowler.com/articles/mocksArentStubs.html>.  A fake HBase would probably be in-process and have only in-memory tables.  But it might be a fair amount of effort to get all the semantics right.
>

ZK comes up fast.

Then its hbase and hdfs coming up.  We're probably equally slow coming
up (I haven't looked at this in a while).

I'm all ear regards any suggestions for making our test suite run
faster or breaking up our balls of code so testing is made easier.

Regards hbase, its not my idea (it was the gumgum fellows IIRC) but I
like the idea of grafting HTableInterface on to the front of an
HRegion instance or some such.  Currently it requires too much
shimming.  If I was staring over, the StoreFile, MemStore, HRegion,
HRegionServer APIs would be HTable APIs; they'd all implement the same
interface (In the old days we had an Incommon interface which was the
intersection of HTable and HRegion interfaces so you could run same
test code directly against an HRegion instance and then run it
remotely).

St.Ack

Re: hbase test library

[Patrick Angeles <pa...@gmail.com>]

I still think static mocks are easier to work with (and read), but yes, in
their absence Mockito and friends make a huge difference. I'm okay with
using mocking tools here or rolling my own static mocks for HTableInterface,
etc.

But yes, I'm thinking more of a 'fake' in-process and in-memory HBase
cluster for integration testing. The minicluster would be an acceptable
replacement (except for the startup overhead as mentioned). You could also
run HBase in local mode, but what if you wanted to put a breakpoint on your
coprocessors / filters?

- P
On Fri, Apr 29, 2011 at 3:11 PM, Joe Pallas <jo...@oracle.com>wrote:

>
> On Apr 29, 2011, at 11:12 AM, Stack wrote:
>
> > On Fri, Apr 29, 2011 at 10:27 AM, Joe Pallas <jo...@oracle.com>
> wrote:
> >> We’ve been using Mockito to mock HTable and friends and are pretty happy
> with its ease of use and capabilities.
> >>
> >
> > To avoid going to an hbase backing cluster?
>
> We have tests that use the minicluster and tests that use mocks (or both).
>  Since we do TDD, we need tests that cover some cases that are pretty hard
> to do without mocks.  For example, a test that verifies the implementation
> loops until checkAndPut is successful is hard to do without mocks.
>
> I will say that startup time for the minicluster is pretty bad for unit
> testing.  Maybe what the original request was really asking for is what
> Fowler calls "fakes" <
> http://martinfowler.com/articles/mocksArentStubs.html>.  A fake HBase
> would probably be in-process and have only in-memory tables.  But it might
> be a fair amount of effort to get all the semantics right.
>
> joe
>
>

Re: hbase test library

[Joe Pallas <jo...@oracle.com>]

On Apr 29, 2011, at 11:12 AM, Stack wrote:

> On Fri, Apr 29, 2011 at 10:27 AM, Joe Pallas <jo...@oracle.com> wrote:
>> We’ve been using Mockito to mock HTable and friends and are pretty happy with its ease of use and capabilities.
>> 
> 
> To avoid going to an hbase backing cluster?

We have tests that use the minicluster and tests that use mocks (or both).  Since we do TDD, we need tests that cover some cases that are pretty hard to do without mocks.  For example, a test that verifies the implementation loops until checkAndPut is successful is hard to do without mocks.

I will say that startup time for the minicluster is pretty bad for unit testing.  Maybe what the original request was really asking for is what Fowler calls "fakes" <http://martinfowler.com/articles/mocksArentStubs.html>.  A fake HBase would probably be in-process and have only in-memory tables.  But it might be a fair amount of effort to get all the semantics right.

joe

Re: hbase test library

[Stack <st...@duboce.net>]

On Fri, Apr 29, 2011 at 10:27 AM, Joe Pallas <jo...@oracle.com> wrote:
> We’ve been using Mockito to mock HTable and friends and are pretty happy with its ease of use and capabilities.
>

To avoid going to an hbase backing cluster?
St.Ack

Re: hbase test library

[Joe Pallas <jo...@oracle.com>]

On Apr 29, 2011, at 6:09 AM, Patrick Angeles wrote:

> It would be a considerable help to the developer community if there were a
> set of mock classes for HTable and friends to help with unit testing. 

Maybe I’m misunderstanding the context, but why is there a need for static mocks?  Dynamic, reflection-based mock systems (JMock, PowerMock, EasyMock, Mockito, I'm sure there are more) are pretty much the norm these days.

We’ve been using Mockito to mock HTable and friends and are pretty happy with its ease of use and capabilities.

joe