Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: <528A7254.9050304@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>
	<CADxc9BkN3K3dUF1NiXs4-JC9zMhupdYmB41B79ps0jZ9_vAdQg@mail.gmail.com>
	<528A7254.9050304@gmail.com>
Date: Mon, 18 Nov 2013 15:54:33 -0500
Message-ID: 
 <CAGUtCHoVagXO2nzpUs=nXQWDbE3-_afEixPsD9h8pBTo0OPxDg@mail.gmail.com>
Subject: Re: [VOTE] Deprecate mock in 1.6.0
From: Keith Turner <keith@deenlo.com>
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=bcaec547ca8d54e5e304eb79c115

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

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

--bcaec547ca8d54e5e304eb79c115--