+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 <vi...@apache.org> wrote: > Sent from my phone, please pardon the typos and brevity. > On Nov 14, 2013 4:46 PM, "Josh Elser" <josh.el...@gmail.com> 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" <josh.el...@gmail.com> 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 > >>>> > >> >
