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