>From an API perspective, I like how easy it is to spin up my ProxyServer in a MiniAccumuloCluster and work through the code in my C++ wrapper around the proxy client. It keeps the access to the Accumulo stack very clean. However, I really do like the idea of having the option to run the MiniAccumuloCluster manually outside of both the proxy and the integration test environments, (maybe with a bash script or a main method?). If there was a tarball that I could extract into a directory and a script that I could run to start it up with known settings, it would replace my having to install zookeeper & accumulo manually when I want to run tests on my own box.
On one hand, it makes it a little more complicated to start up the proxy. But on the other hand, it makes starting up a local instance of Accumulo for development much less complicated. On Mon, Apr 29, 2013 at 12:27 PM, Christopher <[email protected]> wrote: > 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 > http://gravatar.com/ctubbsii > > > 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]> > >> >> Date: 04/26/2013 7:27 AM (GMT-05:00) > >> >> To: Accumulo Dev List <[email protected]> > >> >> 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 > >> >> http://gravatar.com/ctubbsii > >> >> > >> >> > >> >> On Thu, Apr 25, 2013 at 11:01 PM, Corey Nolet <[email protected]> > >> 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. > >> >> > >> > -- Corey Nolet Senior Software Engineer TexelTek, inc. [Office] 301.880.7123 [Cell] 410-903-2110
