[
https://issues.apache.org/jira/browse/DRILL-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated DRILL-2812:
----------------------------------
Fix Version/s: 1.2.0
> Regularize JDBC unit-level unit test class naming
> -------------------------------------------------
>
> Key: DRILL-2812
> URL: https://issues.apache.org/jira/browse/DRILL-2812
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC
> Reporter: Daniel Barclay (Drill)
> Assignee: Daniel Barclay (Drill)
> Priority: Minor
> Fix For: 1.2.0
>
>
> For JDBC Driver unit-level unit tests (those focused on particular classes or
> interfaces and named based on those types, vs. those focused on, say
> SQL-level features), the naming pattern(s) should be cleaned up
> (reviewed/designed and made more consistent).
>
> Background on non-test files (per DRILL-2089's started and planned changes):
> For (non-test) interfaces and classes for JDBC-defined interfaces, the usual
> pattern is:
> - there is an interface {{java.sql.Something}} defined by JDBC,
> - there is a Drill interface {{org.apache.drill.jdbc.DrillSomething}} (for
> Drill-specific Javadoc and any Drill-specific extension methods; in Drill's
> driver's published interface), and
> - there is a Drill implementation class
> {{org.apache.drill.jdbc.impl.DrillSomethingImpl}} with the main
> implementation of the interfaces' methods (in itself or a superclass).
> Also, there is the driver _class_ at {{org.apache.drill.jdbc.Driver}}, also
> in Drill's driver's published interface, which delegates as much as possible
> to implementation class {{org.apache.drill.jdbc.impl.DriverImpl}}.
> There are also various implementation-only classes.
>
> [EDITING STILL IN PROGRESS; FOLLOWING IS STILL TO BE ASSIMILATED:]
> ?? 1:
> - ...jdbc.impl.DrillSomethingImplTest for unit-level unit tests (calling
> DrillSomethingImpl without setting up a connection to a Drillbit, including
> methods not defined by interfaces Something or DrillSomething)
> - ...jdbc.DrillSomethingTest and/or ...jdbc.SomethingTest for
> integration-level unit tests (usually with setting up a connection to a
> Drillbit, calling only methods defined by the related interfaces)
> ?? 2: any need for DrillSomethingTest _and_ SomethingTest (testing extensions
> separately)? (probably not)
> // Maybe:
> // - DrillResultSetImplTest, for typical Xyz -> XyzTest pattern, with Xyz
> being
> // class implementing JDBC interface and Drill's derived interface.
> // - DrillResultSetTest, for mostly-typical Xyz -> XyzTest pattern, but with
> Xyz
> // based on full Drill interface whose methods are being tested
> // - ResultSetTest, for mostly-typical Xyz -> XyzTest pattern, but with Xyz
> // based on just JDBC interface whose methods are being tested.
> // - Multiple tests, perhaps:
> // - DrillResultSetImplTest for implementation-class-specific tests (e.g.,
> // non-public methods), plus
> // - DrillResultSetTest (or ResultSetTest) for tests for public methods.
> // Recall that although main pattern for non-test types is (to be)
> // java.sql.Xyz vs. ...drill.jdbc.DrillXyx vs. ...drill.jdbc
> impl.DrillXyzImpl,
> // there are exceptions, such as java.sql.DatabaseMetaData vs.
> // ...drill.jdbc.DrillDatabaseMetadata vs. ...drill.jdbc.impl.MetaImpl,
> since
> // the implementation class for DrillDatabaseMetadata used MetaImpl.
> // (Any low-level unit test for MetaImpl should be in a MetaImplTest, while
> // higher-/integration-level tests should be in DrillDatabaseMetadataTest.)
> // Factor in the subdividing into separate test classes (e.g.,
> // DatabaseMetaDataGetColumnsTest).
> // (Related to DRILL-2089 (moving internal types to ...jdbc.impl package).)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
