JSR 235 TCK

Overview

The JSR 235 TCK is a suite of test cases designed to provide a comprehensive analysis of an SDO implementation as compared with the JSR 235 SDO specification.  These test cases are executed and analyzed through the use of the JUnit testing framework.  The JSR 235 TCK Test Harness is an ANT build script that provides compilation, packaging and test execution services for the JSR 235 TCK.

TCK Dependencies

The JSR 235 TCK requires a set of commonly used open source tools for compilation and execution.  

 

 

Install and configure ANT appropriately for your development platform.  The other three tools’ jar files may be placed in the \tck\lib directory.  From there, they will be picked up during the ANT script execution.

RuntimeHelper Interface

The JSR 235 TCK has been designed to be used by all JSR 235 specification compliant implementations.  With that in mind a mechanism was needed to provide implementation specific resources not available through the standard SDO API.  The RuntimeHelper interface provides this mechanism.  Before an implementation can be tested with the TCK, you will need to create/enhance a class that implements the RuntimeHelper interface.  The RuntimeHelper interface can be found in the commonj.sdo.impl.RuntimeHelper.java file.

Test Harness Directions

The test harness will compile the TCK, package the results into a Jar file and then execute the test cases.  Below is a sequence of events needed to unpack and execute the TCK.

 

  1. 1.A test location needs to be identified and a directory created.  

    1. a.Create a new directory (for example ‘.\tck’) 

    2. b.Unzip the jsr235tck.zip file into this new directory. 

  2. 2.Create an implementation specific JUnit test suite.  See com.ibm.sdo.tck.framework.ImplTestSuiteExample.java. 

  3. 3.Customize the jsr235tckProperties.xml file to match your system configuration. 

    1. a.The <testsuite> value should be set to your implementation’s top level test suite (this is the class you’ve customized in step #2. 

    2. b.Provide the location where all implementation specific jar files are located using the <lib> tag. 

  4. 4.Verify required tools are available for test harness execution. 

    1. a.See TCK Dependencies above. 

  5. 5.Perform the test harness execute target. 

    1. a.Using ANT syntax ‘ant –f jsr235tckBuild.xml execute’ 

    2. b.This target will call multiple internal targets to compile and package the tck, and then execute the implementation specific test suite.   

    3. c.The results of the execution are stored in the \results directory in the result.xml file. 

  6. 6.As needed, perform execution clean target. 

    1. a.This target will clean out the results of the execute target.  It deletes the \results directory and targeted contents of the \lib directory. 

 

Testing Static Function

The SDO specification does not define the means by which implementations must generate static SDO classes.  Because of this limitation, The TCK tests statically generated code based on the assumption that the implementers have added their generated code to their test harness classpath prior to invoking the TCK.  Adding these generated classes to the classpath will hide the generated interfaces that are included in the TCK.  The TCK will report an error if it finds it is using the TCK provided interfaces.  Adding the generated classes to the TCK classpath is accomplished as follows:

 

  1. 1.Execute implementation’s static generator against the src/main/resources/staticTest/simple.xsd schema. 

  2. 2.After execution the following set of interfaces (at a minimum) should have been created: 

    1. a.com.ibm.sdo.tck.staticTest/ComplexType1.java 

    2. b.com.ibm.sdo.tck.staticTest/CT2.java 

  3. 3.Take all the generated artifacts and package them into a jar file. 

  4. 4.Place the new jar into the directory identified in the jsr235tckProperties.xml file by the <lib> tag. 

 

The SDO implementer’s test harness must also ensure that the SDO Types associated with the generated classes are defined within a HelperContext instance.  This requires the implementer to provide an implementation of the RuntimeHelper.defineStaticTypes() method in its test harness' implementation of the RuntimeHelper interface.  The method call is provided with the HelperContext instance, the namespace of the schema that describes the required classes and a location hint in the form of a path indicating where the schema file may be found. This method should be called once per namespace prior to each test that requires static classes.

 

Revision History

 

2009/06/15

2009/05/18

2009/03/04

2009/02/16

2008/10/06

2008/09/29

2008/09/22

2008/09/08

2008/08/25

2008/08/14

2008/07/28

2008/06/25

2008/06/11

2008/05/29

2008/05/28

2008/05/14