drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Rogers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-5320) Refactor OptionManager to allow better unit testing
Date Tue, 07 Mar 2017 17:40:37 GMT

    [ https://issues.apache.org/jira/browse/DRILL-5320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899821#comment-15899821

Paul Rogers commented on DRILL-5320:

Proposed new interface (comments omitted):

public interface OptionSet {
  OptionValue getOption(String name);
  boolean getOption(TypeValidators.BooleanValidator validator);
  double getOption(TypeValidators.DoubleValidator validator);
  long getOption(TypeValidators.LongValidator validator);
  String getOption(TypeValidators.StringValidator validator);

> Refactor OptionManager to allow better unit testing
> ---------------------------------------------------
>                 Key: DRILL-5320
>                 URL: https://issues.apache.org/jira/browse/DRILL-5320
>             Project: Apache Drill
>          Issue Type: Sub-task
>          Components: Tools, Build & Test
>    Affects Versions: 1.10.0
>            Reporter: Paul Rogers
>            Assignee: Paul Rogers
>             Fix For: Future
> The {{OptionManager}} interface serves two purposes:
> * Create and modify options
> * Access option values
> The implementations  of this class are integrated with the rest of Drill, making it difficult
to use the classes in isolation in unit testing. Further, since operators are given the full
interface, the operator has the ability to modify options, and so each unit test should either
verify that no modification is, in fact, done, or must track down modifications and test them.
> For operator and sub-operator unit tests we need a simpler interface. As it turns out,
most low-level uses of {{OptionManager}} are all read-only. This allows a simple refactoring
to enhance unit testability: create a new super-interface {{OptionSet}}, which provides only
the read-only methods.
> Then, refactor low-level classes (code generation, compilers, and so on) to use the restricted
{{OptionSet}} interface.
> Finally, for unit tests, create a trivial, map-based implementation that can be populated
as needed for each specific test.

This message was sent by Atlassian JIRA

View raw message