-Re: Transition from MockAccumulo to a full blown local instance
Jesse Yates 2011-10-07, 13:18
I can definitely see the advantages of not wanting to spin up a mini cluster
for testing - its currently killing HBase's test suite run time.
As far as cutting down the mocks, I'm all for it. One of the big advantages
of having a mini cluster run in the same jvm is that it behaves _exactly_
like a real cluster, so if your tests pass locally, then there is a very
good chance that it will run in production. Using the mock mechanism, its
more of a sanity check - yeah, its doing what I think, but I'm still praying
that it won't break my cluster.
I opened ACCUMULO-14 to discuss it further.
On Wed, Oct 5, 2011 at 12:33 PM, Keith Turner <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 5, 2011 at 1:17 AM, Jesse Yates <[EMAIL PROTECTED]>
> > Maintaining a real instance and a mock instance ends up creating a lot of
> > extra work for dev's by ensuring that there impls are kept synchronized.
> > Instead, we should move to an actual hosted instance of Accumulo running
> > the local file system. This would mean less work in the long run to
> > a separate instance and better testing for users and new features.
> > It will also mean we can create an instance of Accumulo running in local
> > mode that users can spin up when trying out the system. Therefore once we
> > have a local instance, we would want to update the documentation on run
> > scripts to enable using the local instance.
> > What does everyone think?
> > -Jesse Yates
> We have discussed some aspects of this. There are two nice things
> about the way mock works now. First, its very fast to create a mock
> instance which means that unit test run very quickly. Second, its all
> in process which is useful for debugging.
> You mentioned one of the drawbacks, more work to maintain it. Another
> drawback is that it may behave differently in some circumstances,
> since its another implementation.
> We have discussed possibly making mock leverage more of the actual
> accumulo code, but possibly keep it in process for speed and
> debugging. We know it needs improvement, and are open to suggestions.
> We need to work out a plan/design for how we want to move forward.