accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [VOTE] Deprecate mock in 1.6.0
Date Mon, 18 Nov 2013 21:24:10 GMT
On Mon, Nov 18, 2013 at 4:01 PM, John Vines <vines@apache.org> wrote:

> And I'm a firm advocate of #2. Joey makes a good point about the foibles of
>

Do you think new features like namespaces and conditional writer should be
rejected unless they have support for mock?


> premature deprecation (albeit not as drastic as his case) and Eric made an
> extremely cromulent point about the benefits of mock that aren't available
> elsewhere currently.
>
>
> On Mon, Nov 18, 2013 at 3:54 PM, Keith Turner <keith@deenlo.com> wrote:
>
> > On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <josh.elser@gmail.com>
> wrote:
> >
> > > I'll put the question out there:
> > >
> > > Is it an immediate non-starter to deprecate something that doesn't have
> > an
> > > immediate replacement?
> > >
> > > 1. You can still use it even if it's deprecated (and our usage of
> > > deprecated typically falls under "we won't remove it before version X
> if
> > > not later")
> > > 2. We know there are problems with it.
> > > 3. We know we should be making other tools that better replace it (MAC)
> > or
> > > just give you a specific piece of functionality (iterator smoke-test
> > > framework).
> > >
> > > Is this just my interpretation of how to interpret @Deprecated? It
> seems
> > > completely logical to deprecate something we know isn't where we want
> to
> > go
> > > even if we aren't to where we want to go. Then, we start focusing on
> > > making/improving the tools we want. This advertises to users that maybe
> > > they might not want to rely on MockAccumulo.
> >
> >
> > I agree.  I am thinking that if we do not maintain it, then its
> > deprecated whether we declare it or not.  We at least  3 options :
> >
> > 1. Deprecate mock
> > 2. Maintain mock (add new Accumulo features and actively fix bugs)
> > 3. Leave it as is
> >
> > I think we should choose 1 or 2, but not choose 3.
> >
> >
> >
> > >
> > > On 11/18/13, 2:51 PM, Eric Newton wrote:
> > >
> > >> I had this basic interaction with a user today:
> > >>
> > >> "I upgraded my old-style Filter to the Filter-as-iterator-Filter, how
> > do I
> > >> test it?"
> > >>
> > >> And the easiest thing to tell them was "use MockAccumulo".  Without a
> > >> better answer, I'm not for deprecating Mock.
> > >>
> > >> I agree that there is considerable effort in trying to keep Mock
> > >> up-to-date, to the extent that I've not bothered to fix many of the
> > >> failings of Mock.
> > >>
> > >>
> > >>
> > >> On Mon, Nov 18, 2013 at 2:09 PM, Christopher <ctubbsii@apache.org>
> > wrote:
> > >>
> > >>  Eric,
> > >>>
> > >>> Is there a reason these cannot be done in Mockito or EasyMock?
> > >>>
> > >>> --
> > >>> Christopher L Tubbs II
> > >>> http://gravatar.com/ctubbsii
> > >>>
> > >>>
> > >>> On Sun, Nov 17, 2013 at 7:22 PM, Eric Newton <eric.newton@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> -1
> > >>>>
> > >>>> I'm a little more invested in Mock since I wrote the first instance
> of
> > >>>>
> > >>> it.
> > >>>
> > >>>>   I know it does not simulate the accumulo API perfectly.  And
I
> know
> > it
> > >>>> adds some maintenance overhead for anyone adding new features to
the
> > >>>> API.
> > >>>>
> > >>>> However, adding additional testing requirements for a new API is
> > >>>>
> > >>> something
> > >>>
> > >>>> I like.
> > >>>>
> > >>>> Take a counter example: the "file://" hdfs implementation.  It
> allows
> > >>>> you
> > >>>> to use the local file system through the same API you would use
for
> > the
> > >>>> distributed file system.
> > >>>>
> > >>>> Except, it doesn't. It does not behave the same as hdfs.  None
of
> our
> > >>>> recovery tests can use the local fs implementation because it just
> > >>>>
> > >>> doesn't
> > >>>
> > >>>> implement the proper flush semantics.
> > >>>>
> > >>>> Yet dozens of our own tests rely on the speedy availability of
the
> > local
> > >>>>
> > >>> fs
> > >>>
> > >>>> implementation.
> > >>>>
> > >>>> Having a fast way to test iterators that uses a test harness is
not
> > the
> > >>>> same thing as testing the iterators using the same API they would
> use
> > >>>> without Mock.  I have long called for an iterator test harness
to
> > stress
> > >>>> the issues of iterator lifetimes.
> > >>>>
> > >>>> Finally, I would humbly suggest that our software has stabilized
to
> > the
> > >>>> point where we tests at all levels:
> > >>>>
> > >>>> * iterator stress tester
> > >>>> * Mock API
> > >>>> * Integration test using MAC
> > >>>> * System tests that can be run at full scale
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Sat, Nov 16, 2013 at 1:12 PM, Corey Nolet <cjnolet@gmail.com>
> > wrote:
> > >>>>
> > >>>>  +1 for keeping a fast and easy (and well documented) mechanism
for
> > >>>>> debugging iterators. Perhaps the SortedMapiterator is the
> > solution..but
> > >>>>>
> > >>>> the
> > >>>
> > >>>> key words here are 'well documented'
> > >>>>>
> > >>>>> -1 for continuing support a half implemented mock framework
that we
> > >>>>>
> > >>>> have to
> > >>>
> > >>>> maintain. It makes code maintenance very hard when you couldnt,
for
> > >>>>> instance in the 1.3 series, even create a MockBatchDeleter.
As
> Chris
> > >>>>> stated, I agree that using the mock in the past had users walking
> the
> > >>>>>
> > >>>> line
> > >>>
> > >>>> too closely between unit and integration tests. With the mock,
I
> could
> > >>>>> write a bunch of fully valid tests against an iterator without
the
> > >>>>>
> > >>>> ability
> > >>>
> > >>>> to verify that compactions didn't negatively affect my results.
> Except
> > >>>>>
> > >>>> for
> > >>>
> > >>>> being fast, the MAC mostly eliminates the need to use the mock
for
> > that
> > >>>>> kind of test at all while it makes the tests more valid to
an
> actual
> > >>>>> runtime environment.
> > >>>>>
> > >>>>> +1 for mocking framework to be used in relevant unit tests.
There
> are
> > >>>>>
> > >>>> times
> > >>>
> > >>>> when a quick and dirty mock is immensely useful and MAC is slow
and
> > way
> > >>>>> overkill for those tasks. Perhaps it would be worth a ticket
to
> > >>>>>
> > >>>> investigate
> > >>>
> > >>>> replacing the current usages of mockAccumulo (I haven't looked
in
> > >>>>>
> > >>>> awhile)
> > >>>
> > >>>> with said mocking framework.
> > >>>>>
> > >>>>> On Nov 15, 2013 3:29 PM, "Michael Berman" <mberman@sqrrl.com>
> wrote:
> > >>>>>
> > >>>>>>
> > >>>>>> +1 (not really a voter)
> > >>>>>>
> > >>>>>> I think iterator unit tests should use SortedMapIterator,
not
> > anything
> > >>>>>>
> > >>>>> like
> > >>>>>
> > >>>>>> a full accumulo stack, and I think MAC is far more suitable
for
> > >>>>>>
> > >>>>> integration
> > >>>>>
> > >>>>>> tests because it actually runs the same code...it's impossible
for
> > an
> > >>>>>> outsider to tell in which behaviors mock reflects actual
accumulo
> > and
> > >>>>>>
> > >>>>> in
> > >>>
> > >>>> which it does something totally different.
> > >>>>>>
> > >>>>>> I do think MAC needs some help, but I think the process
of
> excising
> > >>>>>>
> > >>>>> mock
> > >>>
> > >>>> from our own tests will flesh out what we need there better than
> > >>>>>>
> > >>>>> anything
> > >>>
> > >>>> else we could do.
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Nov 14, 2013 at 9:20 PM, <dlmarion@comcast.net>
wrote:
> > >>>>>>
> > >>>>>>  +1
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> *From:* Keith Turner [mailto:keith@deenlo.com]
> > >>>>>>> *Sent:* Thursday, November 14, 2013 3:42 PM
> > >>>>>>> *To:* dev@accumulo.apache.org; user@accumulo.apache.org
> > >>>>>>> *Subject:* [VOTE] Deprecate mock in 1.6.0
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Should we deprecate mock accumulo for 1.6.0?  This
was considered
> > >>>>>>>
> > >>>>>> [1]
> > >>>
> > >>>> for
> > >>>>>
> > >>>>>> 1.5.0.  I started thinking about this because I never added
> > >>>>>>>
> > >>>>>> conditional
> > >>>
> > >>>> writer to mock.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
> > >>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> > >>
> >
>

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