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 "TechnologyCompatibilityKit" by MichelleCaisse
Date Wed, 14 Sep 2005 18:36:00 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 MichelleCaisse:
http://wiki.apache.org/jdo/TechnologyCompatibilityKit

The comment on the change is:
Added content for section: Configuration Files, Schemas, Metadata, and XML Test 

------------------------------------------------------------------------------
   6. Decide which test superclass to extend for this test. If your test belongs to a package
with its own superclass, use it. Check what class other test classes in the package extend.
Otherwise extend org.apache.jdo.tck.JDO_Test. If you are starting a new package, consider
whether there are methods or fields that you should factor into a new class which you would
extend.
   1. If your test requires instantiating a pc class, choose one or more existing persistence
capable classes from org/apache/jdo/tck/pc/*. If no existing pc classes are suitable for your
test, see Writing a Persistence Capable Class, below.
   1. Write the test (see Guidelines for Writing Test Code, below).
-  1. If the test requires, provide a schema file, mapping file, xml test data, and a configuration
file (see Configuration Files, Schemas, Metadata, and XML Test Data, below). Otherwise, write
a temporary configuration file for debugging and add an entry to alltests.conf for this test.
The temporary configuration file looks like this:
+  1. If the test requires, provide a schema file, mapping file, xml test data, and a configuration
file (see Configuration Files, Schemas, Metadata, and XML Test Data, below). Also, add an
entry for your configuration file to test/conf/configurations.list. Otherwise, write a temporary
configuration file for debugging and add an entry to alltests.conf for this test. The temporary
configuration file looks like this:
    {{{
  jdo.tck.description = Run one test for debugging
  jdo.tck.testdata = 
@@ -145, +145 @@

  
  = Configuration Files, Schemas, Metadata, and XML Test Data =
  
- (content to be provided)
+ Read this section if you are writing a test that requires xml test data (like org.apache.jdo.tck.mapping.CompletenessTest)
or requires a new mapping and schema.
+ 
+ There are a number of files in addition to the Java test class that must be present for
a test to run.
+ 
+  ||File type||Path||Purpose||
+  ||configuration||test/conf/*.conf||Associates mapping and test data with a test class.||
+  ||schema||test/sql/''database''/''identitytype''/*.sql||Contains SQL DDL commands for generating
the database tables in which persistence capable instances are stored.||
+  ||orm metadata||test/jdo/''identitytype''/''package''/**.orm||Provides the mapping metadata
required by the JDO implementation for mapping fields of pc instances to datastore entities.
See Chapters 15 and 18 of the JDO 2.0 specification for more information.||
+  ||test data||test/testdata/''package''/**.xml||Provides data (field values) for pc instances
read by the Spring Framework used in some tests in the query package and mapping.CompletenessTest,
which tests XML metadata.||
+  ||jdo metadata||test/jdo/''identitytype''/''package''/**.jdo||Provides the metadata required
by the JDO implementation for persisting pc instances. See Chapter 18 of the JDO 2.0 specification
for more information.||
+ 
+ Each invocation of maven is driven by a list of configuration files. If you do not set ''jdo.tck.cfglist''
on the command line, maven will read the list of configurations from test/conf/configurations.list,
installing the schema and running tests for all configurations. Typically when you debug a
test, you will specify a single configuration on the command line.  These properties are set
in a configuration file:
+ 
+  *jdo.tck.description - A text description of the purpose of this test configuration
+  *jdo.tck.testdata - The full path below test/testdata to the xml test data file
+  *jdo.tck.standarddata - The full path below test/testdata to the xml standard data file,
used in cases where the test modifies the data before persisting it; the retrieved data is
then compared to the standard data, not the original test data 
+  *jdo.tck.mapping - A number that specifies both the orm mapping file and schema file to
be used for this test (more below)
+  *jdo.tck.classes - The fully-specified name of the test class to be executed
+ 
+ The default schema file is named schema.sql. There is one schema.sql for each database and
identity type. It creates database tables for all of the pc classes used in the tests. In
order to test different mappings, some tests require a different schema.  These are named
schema''N''.sql, where ''N'' is the number assigned to the jdo.tck.mapping property. Each
schema file first creates and sets and sql schema specific to the identity type and jdo.tck.mapping
value. For example:
+  {{{
+ CREATE SCHEMA applicationidentity3;
+ SET SCHEMA applicationidentity3;
+ }}}
+ Each schema file must also drop all database entities before creating them to ensure that
the schema will be clean at the start of each test run.
+ 
+ The default orm metadata file is named package-''database''.orm or ''classname''-''database''.orm.
There is one .orm file for each database and package or class. Configurations that use a different
mapping for a particular pc package use an orm metadata file named package-''databaseN''.orm,
where N is the jdo.tck.mapping value described just above. In this way, there is a one-to-one
association between a schema''N''.sql file and a package-''databaseN''.orm file.
+ 
+ Provide a test data file for any new configuration that uses the Spring Framework methods
to compare a persisted object graph to a standard. Currently the CompletnessTest and some
tests in the query package use the Spring Framework to create an object graph from xml data.
If the test modifies the test data before persisting it, you must provide a standard data
file which specifies the object graph that will match the retrieved data.
+ 
+ Unless you write a new persistence capable class, you do not have to create a new jdo metadata
file. The correct jdo file is found based on the class name, the identity type under test,
and rules for file naming and location described in the specification.
  
  = Writing a Persistence Capable Class =
  

Mime
View raw message