accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Corey Nolet <>
Subject Re: Integration Tests
Date Sun, 28 Apr 2013 11:45:48 GMT
This was exactly the type of response i was looking for. Thanks Chris!

Sent from my Verizon Wireless 4G LTE Smartphone

-------- Original message --------
From: Christopher <> 
Date: 04/28/2013  1:45 AM  (GMT-05:00) 
To: Accumulo Dev List <> 
Subject: Re: Integration Tests 
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
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

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.

Christopher L Tubbs II

On Fri, Apr 26, 2013 at 11:40 AM, Keith Turner <> wrote:
> On Fri, Apr 26, 2013 at 10:18 AM, Corey Nolet <> 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 <>
>> Date: 04/26/2013  7:27 AM  (GMT-05:00)
>> To: Accumulo Dev List <>
>> Subject: Re: Integration Tests
>> The maven-failsafe-plugin is already configured to execute integration
>> tests in the 1.5 branch and trunk. Simply name your JUnit classes to
>> execute with the pattern of "*IT" (vs. "*Test" for unit tests), and
>> they'll execute during the integration test phase of the build
>> lifecycle. That way, they won't slow down a "mvn package" build, but
>> they'll still get executed for a full build "mvn verify".
>> --
>> Christopher L Tubbs II
>> On Thu, Apr 25, 2013 at 11:01 PM, Corey Nolet <> wrote:
>> > Would it make sense to start putting more integration tests for tablet
>> servers, master, connector, etc… inside of the accumulo-test module (or
>> some other module)? Seems like it'd be useful to have tests at the various
>> layers. Until we have a plugin to start up the mini acc cluster once and
>> only once, I don't want to drastically slow down the build. I would,
>> however, like to have some integration tests for a current ticket I'm
>> working on.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message