Re: [VOTE] Deprecate mock in 1.6.0
On Thu, Nov 14, 2013 at 2:41 PM, Keith Turner wrote: > 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 > Would deprecating it in 1.6.0 mean it is removed in 1.7.0 or in 1.8.0? Does it impact anything else? Would we not attempt feature parity for 1.6.0 (e.g. conditional writer)? -- Sean
Re: [VOTE] Deprecate mock in 1.6.0
+1 Been bitten by goofy/half-implemented stuff in Mock too many times. I'd rather see effort placed into making MAC a reliable and fast testing mechanism than helping Mock limp along On 11/14/13, 12:41 PM, Keith Turner wrote: 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
Re: [VOTE] Deprecate mock in 1.6.0
+1 On Nov 14, 2013 3:42 PM, "Keith Turner" wrote: > 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 >
Re: [VOTE] Deprecate mock in 1.6.0
+1 (non-binding) Christopher's comment on -878 [1] echoes my thinking. For me, "mock" means "unit tests", and I'd rather use a mock framework (Easymock, Mockito, whatever) than a running cluster (however lightweight) in unit tests. [1]: https://issues.apache.org/jira/browse/ACCUMULO-878?focusedCommentId=13504949&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13504949 On Thu, Nov 14, 2013 at 3:41 PM, Keith Turner wrote: > 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 > -- | - - - | Bill Havanki | Solutions Architect, Cloudera Government Solutions | - - -
Re: [VOTE] Deprecate mock in 1.6.0
+1 On Thu, Nov 14, 2013 at 3:41 PM, Keith Turner wrote: > 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 >
Re: [VOTE] Deprecate mock in 1.6.0
Sent from my phone, please pardon the typos and brevity. On Nov 14, 2013 2:49 PM, "Josh Elser" wrote: > > +1 > > Been bitten by goofy/half-implemented stuff in Mock too many times. I'd rather see effort placed into making MAC a reliable and fast testing mechanism than helping Mock limp along -1 MAC isn't there yet and I don't think we should deprecate it without a suitable alternative in place > > > On 11/14/13, 12:41 PM, Keith Turner wrote: >> >> 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 >>
Re: [VOTE] Deprecate mock in 1.6.0
Sent from my phone, please pardon the typos and brevity. On Nov 14, 2013 2:49 PM, "Josh Elser" wrote: > > +1 > > Been bitten by goofy/half-implemented stuff in Mock too many times. I'd rather see effort placed into making MAC a reliable and fast testing mechanism than helping Mock limp along -1 We do not have a suitable alternative in place in 1.6 and I don't think we should deprecate it until there is one. > > > On 11/14/13, 12:41 PM, Keith Turner wrote: >> >> 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 >>
Re: [VOTE] Deprecate mock in 1.6.0
On 11/14/13, 2:41 PM, John Vines wrote: Sent from my phone, please pardon the typos and brevity. On Nov 14, 2013 2:49 PM, "Josh Elser" wrote: +1 Been bitten by goofy/half-implemented stuff in Mock too many times. I'd rather see effort placed into making MAC a reliable and fast testing mechanism than helping Mock limp along -1 MAC isn't there yet and I don't think we should deprecate it without a suitable alternative in place Can you provide why you think "MAC isn't there yet" and what you would consider the bar for "suitable alternative" please? On 11/14/13, 12:41 PM, Keith Turner wrote: 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
Re: [VOTE] Deprecate mock in 1.6.0
Sent from my phone, please pardon the typos and brevity. On Nov 14, 2013 4:46 PM, "Josh Elser" wrote: > > On 11/14/13, 2:41 PM, John Vines wrote: >> >> Sent from my phone, please pardon the typos and brevity. >> On Nov 14, 2013 2:49 PM, "Josh Elser" wrote: >>> >>> >>> +1 >>> >>> Been bitten by goofy/half-implemented stuff in Mock too many times. I'd >> >> rather see effort placed into making MAC a reliable and fast testing >> mechanism than helping Mock limp along >> >> -1 >> >> MAC isn't there yet and I don't think we should deprecate it without a >> suitable alternative in place > > > Can you provide why you think "MAC isn't there yet" and what you would consider the bar for "suitable alternative" please? Faster to use, easier to use in junit tests, and easier to debug iterators in an ide. Specifically, the spin up time of mock vs Mac is orders of magnitude. Because of that, junit tests should reuse a mock, which I think the maven plugin should help with, but I don't know how well it works and what the effect is on in IDE testing. Lastly, because tservers spin up in new processes, it makes it overwhelmingly difficult to debug an iterator stack. Either mechanisms to improve debug hooks for the processes or an alternative iterator testing suite is in order. > > >>> >>> >>> On 11/14/13, 12:41 PM, Keith Turner wrote: 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 >>
Re: [VOTE] Deprecate mock in 1.6.0
+1 I'd prefer we get a bit more rigorous about the distinction between integration testing and unit testing. MockAccumulo walks that line too closely, and I think it encourages writing bad tests, with the risk that code relies on incorrect mock behavior. I'd prefer to put some effort into making the accumulo-maven-plugin more robust and feature-ful for actual integration testing. In the meantime, raw MiniAccumuloCluster is suitable for ITs. For actual unit tests, we should encourage the use of EasyMock or Mockito or something like that, and stop trying to test end-to-end behavior in unit tests. To unit test iterators, there's already a SortedMapIterator that allows you to create an iterator from a TreeMap. I don't think we should remove it anytime soon, but we should deprecate it. The sooner we deprecate it, the less burden we have to maintain two implementations of every new feature, and the more time we'll have to spend time on improving the tests in other ways. MiniAccumuloCluster can do everything that MockAccumulo can do. The fact that it doesn't run as fast is not a good enough reason, in my opinion, to avoid deprecating it... especially since the test cases where it is being used (where the performance matters) blur the lines between unit tests and integration tests... and that tends to hurt us in terms of code coverage and test reliability. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Nov 14, 2013 at 3:41 PM, Keith Turner wrote: > 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
Re: [VOTE] Deprecate mock in 1.6.0
+0 - what's the number if I'm undecided? I'd prefer to see one uber-cool one testing mechanism instead of multiples. On Thu, Nov 14, 2013 at 5:54 PM, John Vines wrote: > Sent from my phone, please pardon the typos and brevity. > On Nov 14, 2013 4:46 PM, "Josh Elser" wrote: > > > > On 11/14/13, 2:41 PM, John Vines wrote: > >> > >> Sent from my phone, please pardon the typos and brevity. > >> On Nov 14, 2013 2:49 PM, "Josh Elser" wrote: > >>> > >>> > >>> +1 > >>> > >>> Been bitten by goofy/half-implemented stuff in Mock too many times. I'd > >> > >> rather see effort placed into making MAC a reliable and fast testing > >> mechanism than helping Mock limp along > >> > >> -1 > >> > >> MAC isn't there yet and I don't think we should deprecate it without a > >> suitable alternative in place > > > > > > Can you provide why you think "MAC isn't there yet" and what you would > consider the bar for "suitable alternative" please? > > Faster to use, easier to use in junit tests, and easier to debug iterators > in an ide. > > Specifically, the spin up time of mock vs Mac is orders of magnitude. > Because of that, junit tests should reuse a mock, which I think the maven > plugin should help with, but I don't know how well it works and what the > effect is on in IDE testing. Lastly, because tservers spin up in new > processes, it makes it overwhelmingly difficult to debug an iterator stack. > Either mechanisms to improve debug hooks for the processes or an > alternative iterator testing suite is in order. > > > > > > >>> > >>> > >>> On 11/14/13, 12:41 PM, Keith Turner wrote: > > > 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 > > >> >
Re: [VOTE] Deprecate mock in 1.6.0
On Thu, Nov 14, 2013 at 5:54 PM, John Vines wrote: > Sent from my phone, please pardon the typos and brevity. > On Nov 14, 2013 4:46 PM, "Josh Elser" wrote: > > > > On 11/14/13, 2:41 PM, John Vines wrote: > >> > >> Sent from my phone, please pardon the typos and brevity. > >> On Nov 14, 2013 2:49 PM, "Josh Elser" wrote: > >>> > >>> > >>> +1 > >>> > >>> Been bitten by goofy/half-implemented stuff in Mock too many times. I'd > >> > >> rather see effort placed into making MAC a reliable and fast testing > >> mechanism than helping Mock limp along > >> > >> -1 > >> > >> MAC isn't there yet and I don't think we should deprecate it without a > >> suitable alternative in place > > > > > > Can you provide why you think "MAC isn't there yet" and what you would > consider the bar for "suitable alternative" please? > > Faster to use, easier to use in junit tests, and easier to debug iterators > in an ide. > > Specifically, the spin up time of mock vs Mac is orders of magnitude. > Because of that, junit tests should reuse a mock, which I think the maven > plugin should help with, but I don't know how well it works and what the > effect is on in IDE testing. Lastly, because tservers spin up in new > processes, it makes it overwhelmingly difficult to debug an iterator stack. > Either mechanisms to improve debug hooks for the processes or an > alternative iterator testing suite is in order. > This is a really good point. What about making the deprecation javadoc point to SortedMapIterator? > > > > > > >>> > >>> > >>> On 11/14/13, 12:41 PM, Keith Turner wrote: > > > 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 > > >> >
Re: [VOTE] Deprecate mock in 1.6.0
+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, 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 >
Re: [VOTE] Deprecate mock in 1.6.0
+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" 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, 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 > >
Re: [VOTE] Deprecate mock in 1.6.0
-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 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" 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, 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 > > > >
Re: [VOTE] Deprecate mock in 1.6.0
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 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 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" 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, 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 >> > > >>
Re: [VOTE] Deprecate mock in 1.6.0
On Sun, Nov 17, 2013 at 7:22 PM, Eric Newton 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. > I think Hadoop should fix local fs to have correct behavior. Just like we should fix Mock to have correct behavior if we are going to continue to maintain it. > > 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 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" 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, 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 > > > > > > >
Re: [VOTE] Deprecate mock in 1.6.0
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 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 > 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 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" 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, 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 > >> > > > >> >
Re: [VOTE] Deprecate mock in 1.6.0
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 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 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 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" 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, 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 writ
Re: [VOTE] Deprecate mock in 1.6.0
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 certainly isn't a great fit for unit tests that can and should execute quickly. -Joey On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser 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 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 >>> 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 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 curre
Re: [VOTE] Deprecate mock in 1.6.0
On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser 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 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 >>> 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 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" wrote: > >> >> +
Re: [VOTE] Deprecate mock in 1.6.0
And I'm a firm advocate of #2. Joey makes a good point about the foibles of 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 wrote: > On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser 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 > 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 > >>> 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 > 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 t
Re: [VOTE] Deprecate mock in 1.6.0
On Mon, Nov 18, 2013 at 4:01 PM, John Vines 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 wrote: > > > On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser > 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 > > 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 > > >>> 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 > > 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
Re: [VOTE] Deprecate mock in 1.6.0
On Mon, Nov 18, 2013 at 3:08 PM, Joey Echeverria 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 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 > 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 > >>> 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 > 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 negat
Re: [VOTE] Deprecate mock in 1.6.0
On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser wrote: > I'll put the question out there: > > Is it an immediate non-starter to deprecate something that doesn't have an > immediate replacement? I don't think so. For instance, we may not need the feature, or it may have been poorly designed and unnecessary. In any case, we do have immediate replacements for MockAccumulo. Perhaps they aren't as ideal, but they have the value of being more reliable. > 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. And, I don't think Joey's point about the M/R API in Hadoop applies here. MockAccumulo was never part of our "public API". It's developer-facing and intended for testing... not core to working with Accumulo. -- Christopher L Tubbs II http://gravatar.com/ctubbsii > 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 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 >>> 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 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 t
Re: [VOTE] Deprecate mock in 1.6.0
On Mon, Nov 18, 2013 at 4:26 PM, Christopher wrote: > On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser wrote: > > > 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. > > And, I don't think Joey's point about the M/R API in Hadoop applies > here. MockAccumulo was never part of our "public API". It's > developer-facing and intended for testing... not core to working with > Accumulo. > > Mock most definitely is a part of our public api for 1.4.x and 1.5.x. Both READMEs basically say the same: 9. API The public accumulo API is composed of : * everything under org.apache.accumulo.core.client, excluding impl packages * Key, Mutation, Value, and Range in org.apache.accumulo.core.data. * org.apache.accumulo.server.mini To get started using accumulo review the example and the javadoc for the packages and classes mentioned above. Mock is in org.apache.accumulo.core.client.mock which means it's a part of the public API. -- Sean
Re: [VOTE] Deprecate mock in 1.6.0
Ugh. Okay. I hadn't realized this. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, Nov 18, 2013 at 5:33 PM, Sean Busbey wrote: > On Mon, Nov 18, 2013 at 4:26 PM, Christopher wrote: > >> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser wrote: >> >> > 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. >> >> And, I don't think Joey's point about the M/R API in Hadoop applies >> here. MockAccumulo was never part of our "public API". It's >> developer-facing and intended for testing... not core to working with >> Accumulo. >> >> > Mock most definitely is a part of our public api for 1.4.x and 1.5.x. Both > READMEs basically say the same: > > > 9. API > > The public accumulo API is composed of : > > * everything under org.apache.accumulo.core.client, excluding impl packages > * Key, Mutation, Value, and Range in org.apache.accumulo.core.data. > * org.apache.accumulo.server.mini > > To get started using accumulo review the example and the javadoc for the > packages and classes mentioned above. > > > Mock is in org.apache.accumulo.core.client.mock which means it's a part of > the public API. > > > -- > Sean
Re: [VOTE] Deprecate mock in 1.6.0
A compromise would be to move MockAccumulo to its own subproject, and deprecate the copy resident in the public API. Then, it can start to drift toward a side project that those interested in maintaining can work with, but that does not need to be kept in lockstep with the arrival of new features. The side project never needs to be deprecated, but the core project has the option to migrate away from it over time. Users can switch over to it if they want to continue using it. Bill On Mon, Nov 18, 2013 at 5:45 PM, Christopher wrote: > Ugh. Okay. I hadn't realized this. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Mon, Nov 18, 2013 at 5:33 PM, Sean Busbey > wrote: > > On Mon, Nov 18, 2013 at 4:26 PM, Christopher > wrote: > > > >> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser > wrote: > >> > >> > 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. > >> > >> And, I don't think Joey's point about the M/R API in Hadoop applies > >> here. MockAccumulo was never part of our "public API". It's > >> developer-facing and intended for testing... not core to working with > >> Accumulo. > >> > >> > > Mock most definitely is a part of our public api for 1.4.x and 1.5.x. > Both > > READMEs basically say the same: > > > > > > 9. API > > > > The public accumulo API is composed of : > > > > * everything under org.apache.accumulo.core.client, excluding impl > packages > > * Key, Mutation, Value, and Range in org.apache.accumulo.core.data. > > * org.apache.accumulo.server.mini > > > > To get started using accumulo review the example and the javadoc for the > > packages and classes mentioned above. > > > > > > Mock is in org.apache.accumulo.core.client.mock which means it's a part > of > > the public API. > > > > > > -- > > Sean > -- | - - - | Bill Havanki | Solutions Architect, Cloudera Government Solutions | - - -
Re: [VOTE] Deprecate mock in 1.6.0
I like this idea. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Nov 19, 2013 at 1:22 PM, Bill Havanki wrote: > A compromise would be to move MockAccumulo to its own subproject, and > deprecate the copy resident in the public API. Then, it can start to drift > toward a side project that those interested in maintaining can work with, > but that does not need to be kept in lockstep with the arrival of new > features. > > The side project never needs to be deprecated, but the core project has the > option to migrate away from it over time. Users can switch over to it if > they want to continue using it. > > Bill > > > On Mon, Nov 18, 2013 at 5:45 PM, Christopher wrote: > >> Ugh. Okay. I hadn't realized this. >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Mon, Nov 18, 2013 at 5:33 PM, Sean Busbey >> wrote: >> > On Mon, Nov 18, 2013 at 4:26 PM, Christopher >> wrote: >> > >> >> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser >> wrote: >> >> >> >> > 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. >> >> >> >> And, I don't think Joey's point about the M/R API in Hadoop applies >> >> here. MockAccumulo was never part of our "public API". It's >> >> developer-facing and intended for testing... not core to working with >> >> Accumulo. >> >> >> >> >> > Mock most definitely is a part of our public api for 1.4.x and 1.5.x. >> Both >> > READMEs basically say the same: >> > >> > >> > 9. API >> > >> > The public accumulo API is composed of : >> > >> > * everything under org.apache.accumulo.core.client, excluding impl >> packages >> > * Key, Mutation, Value, and Range in org.apache.accumulo.core.data. >> > * org.apache.accumulo.server.mini >> > >> > To get started using accumulo review the example and the javadoc for the >> > packages and classes mentioned above. >> > >> > >> > Mock is in org.apache.accumulo.core.client.mock which means it's a part >> of >> > the public API. >> > >> > >> > -- >> > Sean >> > > > > -- > | - - - > | Bill Havanki > | Solutions Architect, Cloudera Government Solutions > | - - -
Re: [VOTE] Deprecate mock in 1.6.0
I think I may have convinced myself otherwise talking to Billie today. MockAccumulo has been the way it is for some time now (two, going on three, major releases). We know it's not ideal and has internal limitations. It doesn't make sense to me to devote more time into it knowing that. For the same reasons, it doesn't make sense for us to spend time moving it for the sake of moving it, because at the end of the day, it's still the same code it was before. 0 to deprecate under the notion that we have other stuff that we can work on that's likely more pressing. I'd say -1, but if someone feels that it is worth the effort, I'm not one to tell them not to do it. Fix MockAccumulo to "throw new NotImplementedExceptions()" where necessary for API additions (if it doesn't already). Strong +1 to seriously look into trying to speeding up MAC, creating an iterator test-harness and other testing tools in the 1.7.0 time frame. On 11/19/13, 1:22 PM, Bill Havanki wrote: A compromise would be to move MockAccumulo to its own subproject, and deprecate the copy resident in the public API. Then, it can start to drift toward a side project that those interested in maintaining can work with, but that does not need to be kept in lockstep with the arrival of new features. The side project never needs to be deprecated, but the core project has the option to migrate away from it over time. Users can switch over to it if they want to continue using it. Bill On Mon, Nov 18, 2013 at 5:45 PM, Christopher wrote: Ugh. Okay. I hadn't realized this. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, Nov 18, 2013 at 5:33 PM, Sean Busbey wrote: On Mon, Nov 18, 2013 at 4:26 PM, Christopher wrote: On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser wrote: 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. And, I don't think Joey's point about the M/R API in Hadoop applies here. MockAccumulo was never part of our "public API". It's developer-facing and intended for testing... not core to working with Accumulo. Mock most definitely is a part of our public api for 1.4.x and 1.5.x. Both READMEs basically say the same: 9. API The public accumulo API is composed of : * everything under org.apache.accumulo.core.client, excluding impl packages * Key, Mutation, Value, and Range in org.apache.accumulo.core.data. * org.apache.accumulo.server.mini To get started using accumulo review the example and the javadoc for the packages and classes mentioned above. Mock is in org.apache.accumulo.core.client.mock which means it's a part of the public API. -- Sean
Re: [VOTE] Deprecate mock in 1.6.0
On Wed, Nov 20, 2013 at 12:13 AM, Josh Elser wrote: > I think I may have convinced myself otherwise talking to Billie today. > > MockAccumulo has been the way it is for some time now (two, going on > three, major releases). We know it's not ideal and has internal > limitations. It doesn't make sense to me to devote more time into it > knowing that. For the same Its good to understand the history. It was introduced in 1.3, major improvements in behavior were made in 1.4, mini was introduced in 1.5, in 1.6 I feel like mock is adrift. > reasons, it doesn't make sense for us to spend time moving it for the sake > of moving it, because at the end of the day, it's still the same code it > was before. > > 0 to deprecate under the notion that we have other stuff that we can work > on that's likely more pressing. I'd say -1, but if someone feels that it is > worth the effort, I'm not one to tell them not to do it. > I think clearly communicating things we developers know to users should be a pressing matter. I suppose we can choose to let users find out the true state of things on their own. I do agree that this discussion has been a time sink. At this point I am just going to give up on this issue. I will not take any action to deprecate mock and I also will not add conditional writer support to it. So the matter is settled for me. For future discussion, if you vote -1 and someone ask you a direct question please answer. Your votes are what prevent someone from moving forward, so you need to defend them. > > Fix MockAccumulo to "throw new NotImplementedExceptions()" where necessary > for API additions (if it doesn't already). > > Strong +1 to seriously look into trying to speeding up MAC, creating an > iterator test-harness and other testing tools in the 1.7.0 time frame. > > > On 11/19/13, 1:22 PM, Bill Havanki wrote: > >> A compromise would be to move MockAccumulo to its own subproject, and >> deprecate the copy resident in the public API. Then, it can start to drift >> toward a side project that those interested in maintaining can work with, >> but that does not need to be kept in lockstep with the arrival of new >> features. >> >> The side project never needs to be deprecated, but the core project has >> the >> option to migrate away from it over time. Users can switch over to it if >> they want to continue using it. >> >> Bill >> >> >> On Mon, Nov 18, 2013 at 5:45 PM, Christopher wrote: >> >> Ugh. Okay. I hadn't realized this. >>> >>> -- >>> Christopher L Tubbs II >>> http://gravatar.com/ctubbsii >>> >>> >>> On Mon, Nov 18, 2013 at 5:33 PM, Sean Busbey >> > >>> wrote: >>> On Mon, Nov 18, 2013 at 4:26 PM, Christopher >>> wrote: >>> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser > wrote: >>> > 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. > > And, I don't think Joey's point about the M/R API in Hadoop applies > here. MockAccumulo was never part of our "public API". It's > developer-facing and intended for testing... not core to working with > Accumulo. > > > Mock most definitely is a part of our public api for 1.4.x and 1.5.x. >>> Both >>> READMEs basically say the same: 9. API The public accumulo API is composed of : * everything under org.apache.accumulo.core.client, excluding impl >>> packages >>> * Key, Mutation, Value, and Range in org.apache.accumulo.core.data. * org.apache.accumulo.server.mini To get started using accumulo review the example and the javadoc for the packages and classes mentioned above. Mock is in org.apache.accumulo.core.client.mock which means it's a part >>> of >>> the public API. -- Sean >>> >>> >> >> >>