Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of eric.newton@gmail.com
 designates 209.85.216.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAL5zq9ZMsgODbJSqA=ybrz7iuFztmE1PUKVcnNUe4se7MzV+jw@mail.gmail.com>
References: 
 <CAGUtCHoWhPBM7-HNo2FSGFiCars1thfu2fU677eWNTgvhfXZrw@mail.gmail.com>
	<00d901cee1a9$47686670$d6393350$@comcast.net>
	<CAA+ACqeA5v=_2JBkr7Z2vMwgGoh+HT3pEEHPi=Y4dnaKeg903Q@mail.gmail.com>
	<CAOHP_tENKkJVBr15Vw=uUFaA7MX6Hfj-QZDnKNnMVN7=tBweSg@mail.gmail.com>
	<CADxc9BkUnnQg=h7qHq-uZ=NLyYWOFFkrj9qEpojLDfJPzEUV1A@mail.gmail.com>
	<CAL5zq9ZMsgODbJSqA=ybrz7iuFztmE1PUKVcnNUe4se7MzV+jw@mail.gmail.com>
Date: Mon, 18 Nov 2013 14:51:43 -0500
Message-ID: 
 <CADxc9BkN3K3dUF1NiXs4-JC9zMhupdYmB41B79ps0jZ9_vAdQg@mail.gmail.com>
Subject: Re: [VOTE] Deprecate mock in 1.6.0
From: Eric Newton <eric.newton@gmail.com>
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=089e0149d2c4a0952304eb78e07c

--089e0149d2c4a0952304eb78e07c
Content-Type: text/plain; charset=ISO-8859-1

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

--089e0149d2c4a0952304eb78e07c--