hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <enis....@gmail.com>
Subject Re: Adding frameworks and coding for testabilitywas [Re: Testing the fix for race condition between Compaction and StoreScanner.init]
Date Mon, 25 Nov 2013 19:06:15 GMT
Similar to what Todd describes, I remember using our own co-processors at a
couple of tests for doing fault injection. Since the coprocessors are
embedded in a lot of places, just wrapping the FI into a coprocessor class
worked for me.

The problem with mocking is that, a lot of the tests we have want to change
a single class (lets say Compactor), but have the whole mini cluster up and
running. I've seen some use of FI in the 0.89-fb branch.


On Mon, Nov 25, 2013 at 2:27 AM, Steve Loughran <stevel@hortonworks.com>wrote:

> On 23 November 2013 18:51, Andrew Purtell <apurtell@apache.org> wrote:
> > Personally I would try to mock before adding fault injection framework.
> > (Guilty of doing that in a recent patch-in-progress, but I have come to
> my
> > senses in time.) No objection to fault injection frameworks per se. Using
> > HDFS as an example again, please correct me if I'm mistaken, there was an
> > AOP fault injection framework once but it is currently disabled, a victim
> > of the migration from Ant to Maven, and possibly will be removed.
> That and the fact that not only was it brittle, it was under-understood and
> so undermaintained -people got scared of it, and when it reported problems,
> the "blame the test framework" became the strategy.
> > The
> > trouble with testing frameworks is the added debt they accumulate over
> > time, like everything else. If we commit to adding one, and also use it
> as
> > much as possible, that would be fine with me. Either way, we should
> > definitely discuss the new/proposed framework and commit it on its own
> > JIRA. I'm concerned how one got through the back door on HBASE-9949.
> >
> >
> Another is "test frameworks may impose requirements on the underlying
> code". This exists in YARN where I couldn't make some of the service events
> of YARN-117 final as it screwed up Mockito.
> Things like Guice are very visible here, but if you can adapt your code to
> use it in other ways it may be acceptable.
> --
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.

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