Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # dev - Adding frameworks and coding for testabilitywas [Re: Testing the fix for race condition between Compaction and StoreScanner.init]


Copy link to this message
-
Re: Adding frameworks and coding for testabilitywas [Re: Testing the fix for race condition between Compaction and StoreScanner.init]
Stack 2013-11-22, 20:54
On Wed, Nov 20, 2013 at 3:27 PM, Jonathan Hsieh <[EMAIL PROTECTED]> 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?
St.Ack