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 <[email protected]> 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 <[email protected]>
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 <[email protected]> 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" <[email protected]> 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, <[email protected]> wrote:
+1
*From:* Keith Turner [mailto:[email protected]]
*Sent:* Thursday, November 14, 2013 3:42 PM
*To:* [email protected]; [email protected]
*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
