On Mon, Nov 18, 2013 at 4:01 PM, John Vines <vi...@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 <ke...@deenlo.com> wrote: > > > 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. > > > > > > 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 <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 > > >>>>>>> > > >>>>>>> > > >>>>> > > >>> > > >> > > >
