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:29:05 GMT
On Mon, Nov 18, 2013 at 3:08 PM, Joey Echeverria
<joey+ml@clouderagovt.com>wrote:

> One word of warning. Hadoop deprecated the original MR API before the
> new API had feature parity and we're not stuck with both
> implementations, probably for the lifetime of Hadoop's MR bindings.
> I'm not in favor of deprecating something that people still have to
> use. You should deprecate when you have something for people to
> migrate to. I think MAC will fit some of the use cases, but it
>

For the use case of testing iterators quickly we have an alternative,
SortedMapIterator.  For integration testing we have mini.


> certainly isn't a great fit for unit tests that can and should execute
> quickly.
>

Can you give some examples?


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