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
>
>