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