drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Barclay (Drill) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DRILL-2812) Regularize JDBC unit-level unit test class naming
Date Fri, 17 Apr 2015 00:57:58 GMT
Daniel Barclay (Drill) created DRILL-2812:

             Summary: 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

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),
- 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.



?? 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

?? 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

View raw message