Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 27 Sep 2012 05:01:07 +1100 (NCT)
From: "Jesse Yates (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <432147994.129419.1348682467885.JavaMail.jiratomcat@arcas>
In-Reply-To: 
 <1529174716.24751.1305761691368.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-3896) Make AssignmentManager standalone
 testable by having its constructor take Interfaces rather than a
 CatalogTracker and a ServerManager
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jesse Yates commented on HBASE-3896:
------------------------------------

I don't think that abstracting out the serverManger and catalogtracker has any real value, at the moment. I don't think there are other implementations of those classes, so pulling out an interface only makes things more complicated, not less. If there were other implementations, for different use cases, then it would make sense to put it all behind an interface to swap them out easily. 

I'm +1 on stack's original comment though that mocking out the classes passes into the AssignmentManager (which is already pretty well setup for testing since it can take in all its dependencies) it enough to make the assignment manager easy to test.

However, I do think there is value in making the serverManger more composition based. Cody mentioned (offline) functions like stop that could be more cleanly abstracted not only here, but around the codebase (I'm thinking you have a StopBuilder that takes in a bunch of things to stop and then builds your 'stopper' so you can close everything out easily).  I'm all for adding a couple new classes to help break out the functions of the SM some more, but that shouldn't happen to just hide functionality from certain parts of the code (e.g. hmaster shouldn't know about function X, so we make another interface that doesn't include that.... leads to a really complex inheritance heirarchy that is hard to reason about and makes the concrete classes even harder to read).

TL;DR anything to make the SM smaller (break out functionality) and composition based would be great, but the root of this ticket should be solvable via mocking. Maybe, at the very least if we still end up doing this, rename the ticket?
                
> Make AssignmentManager standalone testable by having its constructor take Interfaces rather than a CatalogTracker and a ServerManager
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-3896
>                 URL: https://issues.apache.org/jira/browse/HBASE-3896
>             Project: HBase
>          Issue Type: Task
>            Reporter: stack
>            Assignee: Cody Marcel
>
> If we could stand up an instance of AssignmentManager, a core fat class that has a bunch of critical logic managing state transitions, then it'd be easier writing unit tests around its logic.  Currently its hard because it takes a ServerManager and a CatalogTracker, but a little bit of work could turn these into Interfaces.  SM looks easy to do.  Changing CT into an Interface instead might ripple a little through the code base but it'd probably be well worth it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira