db-jdo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jdo Wiki] Update of "TestRunner" by CraigRussell
Date Fri, 10 Jun 2005 22:08:48 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jdo Wiki" for change notification.

The following page has been changed by CraigRussell:
http://wiki.apache.org/jdo/TestRunner

------------------------------------------------------------------------------
  = About TestRunner =
+ An official TCK run requires running all relevant tests in all configurations that are supported
by the Implementation Under Test (IUT). For example, if the JDO implementation supports application
identity and datastore identity and supports MySQL and Derby, then the qualifying TCK test
run must test the entire configuration list (less automatically excluded tests) against application
identity and datastore identity for both MySQL and Derby.
+ 
+ While developing the JDO implementation and removing bugs, it is useful to run a subset
of configurations. This should be easily supported as well. For example, it should be easy
to run just a few tests against application identity on MySQL.
+  
  This project involves rewriting maven.xml so that the same TCK tests can be run in multiple
configurations. For example, the same TCK test program needs to be run with and without security
turned on, and with application identity and datastore identity. When we add different mappings
for Chapter 18 (ORM) tests, the same test will also need to be run with different mappings.
  
  = Requirements =
+  1. Developers must be able to run the JDORI (JPOX) out of the box, and later when desired,
without changing anything, simply by invoking a specific maven goal.
-  1. The user must be allowed to set all of the following configuration parameters: 
+  1. The TCK development team must be able to specify all of the following configuration
parameters: 
  
   *Test description string
  
   *Test class
  
+  *Test data (both input test data and, in some cases, a standard to compare to after updates)
+ 
   *Security on/off
  
+  1.#2 The JDO implementation team must be able to run a subset of the above configurations
in various environments:
   *Application identity / Datastore identity
  
-  *Mapping file (.orm)
+  *Mapping file (.orm) (different databases need different .orm files)
  
-  *Test data (both input test data and, in some cases, a standard to compare to after updates)
- 
-  1.#2 To configure a test run, users should be able to set all configuration parameters
in a text file. 
+  1.#3 To configure a test run, users should be able to set all configuration parameters
in a text file. 
   1. The user must be able to specify either a single test or a list of tests to be run with
a given set of configuration parameters.
   1.  The user must be able to specify multiple configuration settings within one configuration
file, each to be run with one or more test cases.
   1. Each test execution must report the full set of parameters, as listed above.
@@ -60, +66 @@

          A list of one or two identity types to run the TCK on
  
   *exclude.list
-         A list of tests NOT to run the TCK on
+         A list of test classes NOT to execute during a TCK test run
  
  '''Questions:'''
-  1. Do we need to allow for separate database and identity lists for the iut and jdori?
+  1. Do we need to allow for separate database and identity lists for the iut and jdori?
Craig says no. What do you think?
-  1. Do we assume that in general the configurations files will not be changed and users
will override them with the command line options (below)?
+  1. Do we assume that in general the configurations files will not be changed and users
will override them with the command line options (below)? Craig says yes. This will be part
of the "JDO TCK run rules". But we need to allow users to add their specific configuration
files to just run what they want during testing.
-  1. Currently we have two properties in project.properties that can be used to specify the
implementation's support for application or datastore identity.  Should we use these instead
of the identity.list file, allowing override only on the command line?
+  1. Currently we have two properties in project.properties that can be used to specify the
implementation's support for application or datastore identity.  Should we use these instead
of the identity.list file, allowing override only on the command line? Craig thinks that we
should use the "jdori" entries when running the jdori maven goals, and use the "iut" entries
when running the iut maven goals.
  
  == Command Line Options ==
  
@@ -74, +80 @@

      -Ddatabase=<database list>
          Overrides test/conf/db.list by supplying one or more space-separated database names
      -Didentity=<identity type list>
-         Overrides test/conf/identity.list by supplying one or more space-separated identity
types (applicationidentity or datastoreidentity)
+         Overrides the project.properties by supplying one or more space-separated identity
types (applicationidentity or datastoreidentity) to use for this run. Without this option,
running the runtck goal will run both if the implementation supports both.
      -DinstallSchema=<true | false>
          Defaults to false.  Set to true to force schema installation before running tests.
  
  == build and rebuild Goals ==
  
- These goals do not recognize the command line options.  They do a full build and run the
TCK on the JDORI for all configurations, databases, and identity types listed in the configuration
files. [Is this a good idea?]
+ These goals do not recognize the command line options.  They do a full build and run the
TCK on the JDORI for all configurations, databases, and identity types listed in the configuration
files. [Is this a good idea? Craig says yes, but can it be implemented in time?]
  
  == Schema Installation ==
  
- Schema installation takes a significant amount of time and it is difficult to determine
if a schema is up-to-date.  By default, maven.xml installs the schema for all databases, identity
types, and mapping values set for the current invocation only during a full build (maven build
or rebuild goals).  The user may override this behavior by using the -DinstallSchema=true
option with the runtck.jdori or runtck.iut goals to force schema installation.
+ Schema installation takes a significant amount of time and it is impossible to "cheaply"
determine if a schema is up-to-date.  By default, maven.xml installs the schema for all databases,
identity types, and mapping values set for the current invocation only during a full build
(maven build or rebuild goals).  The user may override this behavior by using the -DinstallSchema=true
option with the runtck.jdori or runtck.iut goals to force schema installation.
  
  == Packaging ==
  
@@ -100, +106 @@

   *orm metadata files
   *xml test data files
  
- Currently, the jar files are created and then the directory tree is deleted.  However, the
classes have to be re-enhanced every time an orm or xml file is modified so that the jar file
can be recreated.  To avoid this, we will not delete the tree, thus there is no need to create
a jar file.
+ Currently, the jar files are created and then the directory tree is deleted.  However, the
classes have to be re-enhanced every time an orm or xml file is modified so that the jar file
can be recreated.  To avoid this, we will not delete the tree.
  
  
  == Mapping and Schema Names ==
  
  There may be multiple orm files for a single persistence capable (pc) class or package.
 The orm files are distinguished by different mapping designators in their filenames.  For
example, a given test configuration may run a set of tests on databases derby and mysql with
mapping 4.  The mapping metadata files are package-derby4.orm and package-mysql4.orm; the
schema files are derby/schema4.xml and mysql/schema4.xml. maven passes javax.jdo.option.Mapping=<database
+ mapping designator> to the test, for example javax.jdo.option.Mapping=derby4.
  
- An invocation of maven installs all schemas into the database at once, each into its own
named schema.  The schema name is hard-coded into the .sql DDL file and is named by the identity
type and mapping designator, for example applicationidentity4.  The schema name may be specified
either with the <orm> schema attribute or with the javax.jdo.mapping.Schema property.
To avoid having to add the schema information to each  orm file, the property are passed to
the test on the command line.  
+ An invocation of maven installs all schemas into the database at once, each into its own
named schema.  The schema name is hard-coded into the .sql DDL file and is named by the identity
type and mapping designator, for example applicationidentity4.  The schema name may be specified
either with the <orm> schema attribute or with the javax.jdo.mapping.Schema property.
To avoid having to add the schema information to each orm file, the property to specify the
schema is passed to the test on the command line.  
  
  == Test Data ==
  
@@ -123, +129 @@

  
  == Exclude List ==
  
+ The exclude list is passed to the java test runner. If a class is included in the exclude
list, the class will not be executed by any test configuration.
- The exclude list is passed to the java test runner.
- 
  
  = Design =
  

Mime
View raw message