On Mon, Nov 18, 2013 at 3:08 PM, Joey Echeverria <joey...@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.el...@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 <ctubb...@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.new...@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 <cjno...@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" <mber...@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, <dlmar...@comcast.net> wrote: > >>>>>> > >>>>>>> +1 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> *From:* Keith Turner [mailto:ke...@deenlo.com] > >>>>>>> *Sent:* Thursday, November 14, 2013 3:42 PM > >>>>>>> *To:* dev@accumulo.apache.org; u...@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 > >>>>>>> > >>>>> > >>> > >> > > >
