Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Wed, 19 Mar 2014 20:13:42 +0000 (UTC)
From: "Bill Havanki (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12702384.1395237889688.106061.1395260022830@arcas>
In-Reply-To: <JIRA.12702384.1395237889688@arcas>
References: <JIRA.12702384.1395237889688@arcas>
Subject: [jira] [Commented] (ACCUMULO-2497) InstanceFactory
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/ACCUMULO-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940927#comment-13940927 ] 

Bill Havanki commented on ACCUMULO-2497:
----------------------------------------

This enables easier mocking of Instance objects for testing. For example, take this code:

{code}
public void doSomethingWithInstance() {
  Instance instance = HdfsZooInstance.getInstance();
  X x = instance.foo();
  Y y = instance.bar();
  Z z = y.baz();
  // ...
}
{code}

If I want to test this method, I would normally need to deal with a real, actual {{HdfsZooInstance}} object, and I'd probably have to do all sorts of things to my environment to make sure it works. (Also, the {{x}}, {{y}}, and {{z}} objects would be real, making things even more complex.) I'd rather slip in a mock {{Instance}} object that I can control. That isolates the test to only having to deal with the method. I also won't need any special environment.

In general it's hard to mock static method calls, because most mocking frameworks use class extension to create mock instances. (Ditto for mocking final classes.) The PowerMock test framework does let you mock static method calls, but still it's considered a bad pattern. A better way is to use a factory class which can return your mock objects.

{code}
InstanceFactory ifactory = new HdfsZooInstanceFactory();
public void doSomethingWithInstance() {
  Instance instance = ifactory.getInstance();
  X x = instance.foo();
  Y y = instance.bar();
  Z z = y.baz();
  // ...
}
{code}

Normally the code uses a "real" factory, but for testing the factory is swapped for one that returns mocks. The method under test doesn't even know the difference. Also, the method won't accidentally rely on the object being a particular implementation.

In general, this is just dependency injection, so a further benefit is that if a new, better instance implementation comes along, it  can be swapped in trivially by setting a new factory, instead of by editing static method calls.

> InstanceFactory
> ---------------
>
>                 Key: ACCUMULO-2497
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2497
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>            Reporter: Bill Havanki
>            Assignee: Bill Havanki
>            Priority: Minor
>              Labels: factory, static, testability
>             Fix For: 1.6.1, 1.7.0
>
>
> Working on ACCUMULO-2470 (unit tests for server/base) is made difficult by the heavy dependence on static method calls in our architecture. This ticket is for introducing an {{InstanceFactory}} interface that will greatly ease testing of code that currently retrieves instances via static methods (e.g., {{HdfsZooInstance.getInstance()}}).
> Limitations:
> * Work here should be limited to creating {{InstanceFactory}} and its implementations, and not integrating it into existing code (yet).
> * Work is limited to 1.6 and later. To avoid perturbing the 1.6.0 release no new code may be introduced into the public API ({{Instance}} is in the public API).
> * A refactoring of the client API is being considered (see ACCUMULO-2128), so this change should not further complicate - and should hopefully help - that future effort.


--
This message was sent by Atlassian JIRA
(v6.2#6252)