hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Yates (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-3896) Make AssignmentManager standalone testable by having its constructor take Interfaces rather than a CatalogTracker and a ServerManager
Date Wed, 26 Sep 2012 18:01:07 GMT

    [ 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

View raw message