Uploaded image for project: 'Apache Drill'
  1. Apache Drill
  2. DRILL-2812

Regularize JDBC unit-level unit test class naming

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • None
    • Future
    • Client - JDBC
    • None

    Description

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

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              dsbos Daniel Barclay
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: