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 Thu, 15 Sep 2005 15:30:17 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:
Amplified some information in how-to

------------------------------------------------------------------------------
    PC_CLASS - The name of the persistence capable class instantiated.  If none, delete localSetUp().
If more than one, add additional addTearDownClass(PC_CLASS.class) invocations.
  
   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. If your test requires instantiating a pc class, choose one or more existing persistence
capable classes from org/apache/jdo/tck/pc/*. If the test requires simple pc data, use mylib.PCPoint
and/or mylib.PCRect. If the test requires a complex model with relationships, use one or more
classes in the Company package. 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). 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:
+  1. If the test requires a new mapping or test data, 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 = 
@@ -66, +66 @@

  jdo.tck.mapping = 0
  jdo.tck.classes = org.apache.jdo.tck.your_package_and_test_name
  }}}
-  1. Install the database schema for the test
+  1. If the test requires new metadata for an existing mapping, add it to the .orm and .jdo
files that correspond to your pc classes. Update the files for both application and datastore
identity.  Elements described in the orm dtd should be added to the .orm file.  Otherwise,
add them to the .jdo file.  See Configuration Files, Schemas, Metadata, and XML Test Data,
below, for more information on file names and locations.
+  1. Install the database schema for the test. If you are using the standard schema (jdo.tck.mapping=0),
schema installation takes about 15 minutes. However, it only needs to be repeated after changes
to the schema.
    {{{
    maven -Djdo.tck.cfglist=myConfig.conf installSchema
    }}}
@@ -161, +162 @@

   *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.mapping - A number that specifies both the orm mapping file and schema file to
be used for this test (more below). A value of 0 is used for the standard schema and metadata
files.
   *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:

Mime
View raw message