Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Integration Tests

Copy link to this message
Re: Integration Tests
The proxy connecting to a mock Accumulo is a bit different from
starting an instance of Accumulo, because mock is entirely
self-contained from its the API, and there's nothing to start up.
Having a set of options to use different connector types is different
than having an option to launch different Accumulos. I think. In any
case, it may not need to change as I've described it, but if we want
to support end-to-end integration tests, we need to fix the circular
dependency with the proxy and MiniAccumuloCluster.

I don't know of any other issues with this dependency structure for
1.5, but I do think it should be resolved before 1.5 release, so it
won't create churn in 1.6.

Christopher L Tubbs II
On Mon, Apr 29, 2013 at 10:58 AM, Keith Turner <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 28, 2013 at 1:45 AM, Christopher <[EMAIL PROTECTED]> wrote:
>> I agree that accumulo-test is the best place, but I think we should
>> make it a point that no other modules should depend on accumulo-test
>> for precisely this reason... to provide a place for end-to-end tests
>> of other modules (the assembly module notwithstanding).
>> This is actually a good reason to move MiniAccumuloCluster from test,
>> because the proxy currently has a dependency on it just for
>> MiniAccumuloCluster. That way, end-to-end integration testing that
>> includes even testing of the proxy would make sense to exist in
>> accumulo-test, and we'd avoid a circular dependency. It could be moved
>> to server instead, as it seems to me that it is essentially an
>> alternate server implementation (from the proxy's perspective,
>> anyway). Though, I'm not sure I like the idea that the proxy is
>> dependent on anything other than client code (accumulo-core).
>> Alternatively, the proxy's dependency could be reversed, so that
>> instead of the proxy having an option to start up a
>> MiniAccumuloCluster, the MiniAccumuloCluster could have an option to
> The proxy also has an option to use mock Accumulo.  It seems to follow from
> this that MiniAccumulo would be an option also.
>> start up the proxy. This reversal actually makes more sense to me
> anyway. I never understood why the proxy should have the option to
>> start up Accumulo, Mini or otherwise, as the natural operation, as it
>> seems to me to be a bit backwards: an interface launching the service,
>> rather than a service exposing an interface. I suppose it's not
>> unprecedented, but it seems backwards to me.
>> A third option is to move MiniAccumuloCluster to another module
>> entirely, but I'm not so sure that's necessary or desirable.
>> Any of these options removes the circular dependency, if we're going
>> to make the accumulo-test the place to put end-to-end integration
>> tests.
>> My preference is a combination of the first two options: to put
>> MiniAccumuloCluster in the server module and reverse the dependency,
>> so that proxy only depends on core, and none depend on test.
> Making these changes in 1.6 would be annoying for users (moving MiniAcc to
> another package and deprecating options in the Proxy).  On the other hand
> 1.5. will not be perfect and it needs to be released.  Simplifying
> the dependency tree may avoid problems in the future.  Do you know of any
> issues this dependency structure will cause for 1.5.0?
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>> On Fri, Apr 26, 2013 at 11:40 AM, Keith Turner <[EMAIL PROTECTED]> wrote:
>> > On Fri, Apr 26, 2013 at 10:18 AM, Corey Nolet <[EMAIL PROTECTED]>
>> wrote:
>> >
>> >> So the accumulo-test would be the best place to start putting end to end
>> >> integration tests?
>> >>
>> >
>> > For test against code in modules that can not depend on accumulo-test I
>> > think this is a good place.
>> >
>> >
>> >>
>> >>
>> >> Sent from my Verizon Wireless 4G LTE Smartphone
>> >>
>> >> -------- Original message --------
>> >> From: Christopher <[EMAIL PROTECTED]>