hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Adding frameworks and coding for testabilitywas [Re: Testing the fix for race condition between Compaction and StoreScanner.init]
Date Fri, 22 Nov 2013 20:54:25 GMT
On Wed, Nov 20, 2013 at 3:27 PM, Jonathan Hsieh <jon@cloudera.com> wrote:

> tl;dr if we are going to add new frameworks, please make them a separate
> patch.  another attempt to bring up coding for testability/dep injection
> again.
> I've changed the subject because I really meant this to be a bigger
> discussion about setting up our code to be more testable and using
> conventions that allow us to do dependency injection (ala guava or in a way
> we can use mockito) or deciding to to include this new-to-me
> InjectionHandler frameworks from the 89-fb branch.  Porting HBASE-9949's
> testing code depended this Injector infrastructure that I found
> distasteful.
> This particular example smells funny and looked like another stovepiped
> framework to me --
> 1) It added references and objects to our core code instead of having it
> only present for our tests.
> 2) This made the core code more cumbersome to read.
> 3) Initial version used a brittle convention.   Initially, the injection
> point was identified by passing empty object array of particular size (0
> size mean option 0, size 1 meant injection point 1, etc).  Later changed to
> a enum, As used in the 89-fb branch we have a new global pool of unrelated
> enum/constant values that seemed brittle for further extension.
How did such a mess even get committed?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message