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