Compatibility Testing Your Adapter

Writing and maintaining a custom resource adapter can be a very complex process. Developers commonly discover that their custom adapters do not perform as expected, or that the adapters do not perform the functions expected by Waveset. Even well-written resource adapters will sometimes not work well after the external resource has been upgraded.

Waveset provides a compatibility testing mechanism that you can use to verify the quality of a custom resource adapter. This tester

• Makes it easier for you to write, publish, and maintain a custom adapter

• Makes it easier for you to run the adapter and interpret results

• Focuses on testing the adapter’s supported features as fully as possible in an adapter-independent manner

• Simplifies troubleshooting an adapter

This section describes how to use Waveset’s Compatibility Test Suite. The information is organized as follows:

• How the Compatibility Test Suite Works

• How to Run the Compatibility Tests

• Example 1: Using the Default DataProvider to Run Compatibility Tests

• Example 2: Adding More Data

• Example 3: Finishing the Test Configuration

• Example 4: Executing Javascript or Beanshell Script

• Example 5: Running Tests from Inside the Web Container

How the Compatibility Test Suite Works

Waveset’s Compatibility Test Suite performs a set of standard tests to check the adapter’s supported features. If a particular test requires a feature not provided by the adapter, Waveset skips that test.

The Compatibility Test Suite requires certain information, such as a valid user name and password to run a compatibility test on a resource adapter. You can typically use the standard DataProvider (provided with Waveset) to supply the data required for the test.

For special circumstances, such as when you want to provide information in a class instead of as an expression in XML, you can write a custom DataProvider.

How to Run the Compatibility Tests

To Run the Waveset Compatibility Test Suite

1. Open a command window.

2. At the command prompt, type the lh command using the following format:

   $WSHOME/bin/lh com.sun.idm.testing.adapter.CompatibilitySuite [Options] [testName]

   Where:

   • [options] include:

     • -h: Use to access usage information

       For example:

       Usage: CompatibilitySuite [arguments]

       Valid arguments:

       Argument	Description
       -propsFile value	Path to the properties file
       -formatter value	Formatter to use for formatting output of tests
       -user value	Name of user to execute test as
       -pass value	Plain text password used to log the user on
       -import value	Comma separated list of files (on server) to import
       -toDir value	Directory to put test output in
       -v	Echoes all arguments passed in to the screen
       -h	Displays the usage message

     • -propsFile file: Use to specify a properties file name.

     • -formatter type,path: Use to specify XML, HTML, or plain text and a path in which to put this file.

   • [testName] is a comma-separated list of the tests to run.

   The following properties control how tests are executed:

   Property	Description
   adapter	Classname of the adapter to test
   dp	Name of a custom DataProvider
   importScript	Comma-separated list of paths to the scripts to execute  Note: These scripts return a string of imported XML.
   ns	DataProvider namespace
   includedTests	Comma-separated list of tests to include
   excludedTests	Comma-separated list of tests to exclude
   import	Comma-separated list of files to import

   You can specify these properties directly from the command line, or add them to a properties file specified from the command line. For example,

   lh -DpropName=propValue

   Where properties conflict, properties in the property file specified by propsFile are used.

   ---

   Note –

   When you use the [testName] command, the Compatibility Test Suite ignores the includedTests and excludedTests options.

   ---

   In most cases, the framework provided by Waveset is flexible enough to test the resource adapter. However, you can easily extend the functionality in two places if necessary:

   • You can implement the DataProvider interface to create a custom DataProvider. A custom DataProvider allows data to come from any source.

   • You can implement the CompatibilityHelper interface to provide a CompatibilityHelper. A CompatibilityHelper provides a way to initialize a resource before running tests.

   See the Javadoc for more information about implementing these interfaces and the required naming conventions.

Example 1: Using the Default DataProvider to Run Compatibility Tests

This example illustrates how to run compatibility tests on a SimulatedResourceAdapter using the default DataProvider.

Prepare the Test

Use the following steps to prepare the compatibility tests.

To Prepare the Test

1. Set up the following files:

   sample/compat/example.1/example.properties

   sample/compat/example.1/SimulatedCompatibilityConfig.xml

   ---

   Note –

   The default path to the simulated resource in SimulatedCompatibilityConfig is /tmp/mySimulatedResource.xml.

   You can edit this path if you want to specify a different location.

   ---

2. Before executing the example, copy ant-junit.jar from Apache ant 1.6.5 to your $WSHOME/WEB-INF/lib directory.

Execute the Test

Use the following steps to execute the compatibility tests.

To Execute the Compatibility Test

1. Open a command window.

2. At the prompt, type

   cd $WSHOME

   bin/lh com.sun.idm.testing.adapter.CompatibilitySuite -propsFile sample/compat/example.1/example.properties

   Your output should look similar to the following example:

   TestSuite: com.sun.idm.testing.adapter.CompatibilitySuite Starting internal database server ... DB Server @ jdbc:hsqldb:hsql://127.0.0.1:57022/idm Importing file sample/compat/example.1/SimulatedCompatibilityConfig.xml ’Create(com.sun.idm.testing.adapter.compatibility.Create)’ skipped (unknown) ’Authenticate(com.sun.idm.testing.adapter.compatibility.AuthenticateUser)’ skipped (unknown) ’DeleteExisting(com.sun.idm.testing.adapter.compatibility.DeleteExisting)’ skipped (unknown) ’UpdateExisting(com.sun.idm.testing.adapter.compatibility.UpdateExisting)’ skipped (unknown) ’RenameExisting(com.sun.idm.testing.adapter.compatibility.RenameExisting)’ skipped (unknown) ’EnableExisting(com.sun.idm.testing.adapter.compatibility.EnableExisting)’ skipped (unknown) ’DisableExisting(com.sun.idm.testing.adapter.compatibility.DisableExisting)’ skipped (unknown) ’Iterate(com.sun.idm.testing.adapter.compatibility.Iterate)’ skipped (unknown) ’DeleteMissing(com.sun.idm.testing.adapter.compatibility.DeleteMissing)’ passed (77 ms) Tests run: 9, failures: 0, errors: 0, skipped: 8, Time elapsed: 10864 ms

What Happened

In Execute the Test, the lh command runs the compatibility test with the following argument:

-propsFile sample/compat/example.1/example.properties

Both the adapter and ns properties are required to run the test.

• The adapter property provides the adapter class name to be tested.

• The ns property provides a namespace for the test.

  The DataProvider can use the namespace to set up multiple configurations.

Execute the Test also uses the import property, which imports a list of files into the repository. The import property is similar to lh import filename.

When you start the compatibility test, the tester retrieves the adapter and ns properties from the specified properties.

The default DataProvider retrieves data from the extension element of a namespace#TestData configuration object, which in this example was SimulatedCompatibilityConfig#TestData.

If you do not specify a DataProvider when setting up a test, Waveset used the default DataProvider.

The DataProvider retrieves this SimulatedCompatibilityConfig#TestData configuration object from the repository.

To get the configuration object into the repository, you must define the object in the following file, which is specified in the import property:

sample/compat/example.1/SimulatedCompatibilityConfig.xml

To simplify configuration in Execute the Test, only one test was run with the includedTests=DeleteMissing parameter.

See the Javadoc for more information about which parameters are available and which parameters are required for the different tests.

Example 2: Adding More Data

To run the creation tests, and other tests that create users, you must add more data to the configuration object. In this next example, you must use the default DataProvider again and import an XML file.

Prepare the Test

Use the following steps to prepare the compatibility tests.

To Prepare the Test

1. Set up the following files:

   sample/compat/example.2/example.properties

   sample/compat/example.2/SimulatedCompatibilityConfig.xml

   ---

   Note –

   The default path to the simulated resource in SimulatedCompatibilityConfig is /tmp/mySimulatedResource.xml.

   You can edit this path if you want to specify a different location.

   ---

2. Before executing the example, copy ant-junit.jar from Apache ant 1.6.5 to your $WSHOME/WEB-INF/lib directory.

Execute the Test

Use the following steps to execute the compatibility tests.

To Execute the Test

1. Open a command window.

2. At the prompt, type

   cd $WSHOME

   bin/lh com.sun.idm.testing.adapter.CompatibilitySuite -propsFile sample/compat/example.2/example.properties

   Your output should look similar to the following example:

   TestSuite: com.sun.idm.testing.adapter.CompatibilitySuite Starting internal database server ... DB Server @ jdbc:hsqldb:hsql://127.0.0.1:57022/idm Importing file ./sample/compat/example.2/SimulatedCompatibilityConfig.xml ’Authenticate(com.sun.idm.testing.adapter.compatibility.AuthenticateUser)’ skipped (unknown) ’UpdateExisting(com.sun.idm.testing.adapter.compatibility.UpdateExisting)’ skipped (unknown) ’RenameExisting(com.sun.idm.testing.adapter.compatibility.RenameExisting)’ skipped (unknown) ’Iterate(com.sun.idm.testing.adapter.compatibility.Iterate)’ skipped (unknown) ’DeleteMissing(com.sun.idm.testing.adapter.compatibility.DeleteMissing)’ passed (15 ms) ’EnableExisting(com.sun.idm.testing.adapter.compatibility.EnableExisting)’ passed (259 ms) ’DisableExisting(com.sun.idm.testing.adapter.compatibility.DisableExisting)’ passed (7 ms) ’DeleteExisting(com.sun.idm.testing.adapter.compatibility.DeleteExisting)’ passed (3 ms) ’Create(com.sun.idm.testing.adapter.compatibility.Create)’ passed (3 ms) Tests run: 9, failures: 0, errors: 0, skipped: 4, Time elapsed: 10178 ms

What Happened

You requested additional tests by setting the following property in the properties file:

IncludedTests=DeleteMissing,Create,EnableExisting,DisableExisting,DeleteExisting

These tests required more data from the DataProvider.

To provide this new data, several changes were made to the configuration object specified by SimulatedCompatibilityConfig.xml.

The SimulatedCompatibilityConfig.xml file added a create attribute containing a username, password, and list of user attributes. The default DataProvider uses the create attribute when the compatibility tests ask for the username, password, and attributes required to create a single user.

The SimulatedCompatibilityConfig.xml file also added a schema map.

Example 3: Finishing the Test Configuration

In this next example, you finish the test configuration.

Prepare the Test

Use the following steps to prepare the compatibility tests.

To Prepare the Test

1. Set up the following files:

   sample/compat/example.3/example.properties

   sample/compat/example.3/SimulatedCompatibilityConfig.xml

   ---

   Note –

   The default path to the simulated resource in SimulatedCompatibilityConfig is /tmp/mySimulatedResource.xml.

   You can edit this path to specify a different location by changing two lines in the file.

   ---

2. Before executing the example, copy ant-junit.jar from Apache ant 1.6.5 to your $WSHOME/WEB-INF/lib directory.

3. You must initialize the repository to run the encrypt command.

   For example, use the lh import sample/init.xml command to initialize the repository, where the original file looks like the following:

   <Attribute name="login_infos"> <List> <Object> <Attribute name="sim_user" value="ctUser" /> <Attribute name="sim_password" value="ctPass" /> <Attribute name="shouldfail" value="no" /> </Object> <Object> <Attribute name="sim_user" value="ctUser" /> <Attribute name="sim_password" value="wrongPass" /> <Attribute name="shouldfail" value="yes" /> </Object> <Object> <Attribute name="sim_user" value="ctUser" /> <Attribute name="sim_password"> <!-- result of ’encrypt ctPass’ from lh console --> <EncryptedData>11D1DEF534EA1BE0:-32DFBF32:1165DC91D73: -7FFA|mDBIkSQB3xg=</EncryptedData> </Attribute> <Attribute name="shouldfail" value="no" /> </Object> <Object> <Attribute name="sim_user" value="ctUser" /> <Attribute name="sim_password"> <!-- result of ’encrypt wrongPass’ from lh console --> <EncryptedData>11D1DEF534EA1BE0:-32DFBF32:1165DC91D73: -7FFA|m0n9bAaMx+sKpqs5PmH3eQ== </EncryptedData> </Attribute> <Attribute name="shouldfail" value="yes" /> </Object> </List> </Attribute>

4. In each case, use an encrypt command from the lh console to get an encrypted password that can be decrypted in your environment.

   Run lh console and at the console prompt, type the text in single quotes for each of the preceding EncryptedData entries (for example, encrypt ctPass) and replace the text between <EncryptedData> and </EncryptedData> with the result.

   See the following example:

   <!-- result of ’encrypt ctPass’ from lh console --> <EncryptedData>11D1DEF534EA1BE0:-65F64461:1163AB5A7B2:-7FFA|iMm4Tcqck+M=</EncryptedData> <!-- result of ’encrypt wrongPass’ from lh console --> <EncryptedData>11D1DEF534EA1BE0:-65F64461:1163AB5A7B2:-7FFA|d1/PheqRok+J3uaggtj9Gw== </EncryptedData>

   Alternatively, you can have the DataProvider skip the two login info entries by commenting out the whole block as follows:

   <!-- commented out <Attribute name="login_infos"> <List> <Object> <Attribute name="sim_user" value="ctUser" /> <Attribute name="sim_password" value="ctPass" /> <Attribute name="shouldfail" value="no" /> </Object> <Object> <Attribute name="sim_user" value="ctUser" /> <Attribute name="sim_password" value="wrongPass" /> <Attribute name="shouldfail" value="yes" /> </Object> <Object> <Attribute name="sim_user" value="ctUser" /> <Attribute name="sim_password"> <EncryptedData>11D1DEF534EA1BE0:-32DFBF32:1165DC91D73:-7FFA|mDBIkSQB3xg= </EncryptedData> </Attribute> <Attribute name="shouldfail" value="no" /> </Object> <Object> <Attribute name="sim_user" value="ctUser" /> <Attribute name="sim_password"> <EncryptedData>11D1DEF534EA1BE0:-32DFBF32:1165DC91D73: -7FFA|m0n9bAaMx+sKpqs5PmH3eQ== </EncryptedData> </Attribute> <Attribute name="shouldfail" value="yes" /> </Object> </List> </Attribute> -->

5. Next, copy the new data and paste it inside the <EncryptedData> tag to replace the old data. Be certain there are no extra spaces or line breaks inside the tag.

Execute the Tests

Use the following steps to execute the compatibility tests.

To Execute the Tests

1. Open a command window.

2. At the prompt, type

   cd $WSHOME

   bin/lh com.sun.idm.testing.adapter.CompatibilitySuite -propsFile sample/compat/example.3/example.properties

   Your output should look similar to the following example:

   TestSuite: com.sun.idm.testing.adapter.CompatibilitySuite Starting internal database server ... DB Server @ jdbc:hsqldb:hsql://127.0.0.1:57022/idm Importing file ./sample/compat/example.3/SimulatedCompatibilityConfig.xml ’Create(com.sun.idm.testing.adapter.compatibility.Create)’ passed (31 ms) ’Authenticate(com.sun.idm.testing.adapter.compatibility.AuthenticateUser)’ passed (12 ms) ’DeleteExisting(com.sun.idm.testing.adapter.compatibility.DeleteExisting)’ passed (1 ms) ’DeleteMissing(com.sun.idm.testing.adapter.compatibility.DeleteMissing)’ passed (1 ms) ’UpdateExisting(com.sun.idm.testing.adapter.compatibility.UpdateExisting)’ passed (33 ms) ’RenameExisting(com.sun.idm.testing.adapter.compatibility.RenameExisting)’ passed (5 ms) ’EnableExisting(com.sun.idm.testing.adapter.compatibility.EnableExisting)’ passed (10 ms) ’DisableExisting(com.sun.idm.testing.adapter.compatibility.DisableExisting)’ passed (5 ms) ’Iterate(com.sun.idm.testing.adapter.compatibility.Iterate)’ passed (352 ms) Tests run: 9, failures: 0, errors: 0, skipped: 0, Time elapsed: 10262 ms

What Happened

The line specifying the included tests was removed from the example.properties file, which should run the entire suite.

Additional data is required for the remaining tests, so the SimulatedCompatibilityConfig.xml file was modified to include update, rename, and iterate attributes. These attributes modify users, rename users, and create a set of users over which to iterate. In addition, the file added an login_info attribute that specifies a list of items used to authenticate a user if authentication is supported by the resource adapter.

Finally, the shouldfail attribute, provided in the file under the login info entries, allows negative tests. The tests in the suite should now complete with no errors or skipped tests.

Example 4: Executing Javascript or Beanshell Script

The compatibility tests enable you to execute a javascript or beanshell script and then import the script results into the repository. Either script must return a string that contains the XML to be imported.

Waveset provides an example Apache Velocity template and some supporting beanshell script that uses the template. The beanshell script was created just to fill in the required variables, which makes it very easy to work with the default DataProvider.

Prepare the Test

Prepare the compatibility test to execute with a beanshell script

To Prepare the Test

1. Set up the following files:

   sample/compat/example.4/example.properties

   sample/compat/example.4/SimulatedCompatibilityConfig.bsh

   ---

   Note –

   The default path to the simulated resource in SimulatedCompatibilityConfig is /tmp/mySimulatedResource.xml.

   You can edit this path if you want to specify a different location.

   You must change two lines in the file.

   ---

2. Before executing the example, copy ant-junit.jar from Apache ant 1.6.5 to your $WSHOME/WEB-INF/lib directory.

Execute the Tests

Execute the compatibility tests as follows:

To Execute the Test

1. Open a command window.

2. At the prompt, type

   cd $WSHOME

   bin/lh com.sun.idm.testing.adapter.CompatibilitySuite -propsFile sample/compat/example.4/example.properties

   Your output should look similar to the following example:

   TestSuite: com.sun.idm.testing.adapter.CompatibilitySuite Starting internal database server ... DB Server @ jdbc:hsqldb:hsql://127.0.0.1:57022/idm Executing script /opt/build/dv207518/adapterTestsTemp/waveset/export/pipeline/./sample/ compat/example.4/SimulatedCompatibilityConfig.bsh Importing results ’Create(com.sun.idm.testing.adapter.compatibility.Create)’ passed (25 ms) ’Authenticate(com.sun.idm.testing.adapter.compatibility.AuthenticateUser)’ passed (11 ms) ’DeleteExisting(com.sun.idm.testing.adapter.compatibility.DeleteExisting)’ passed (5 ms) ’DeleteMissing(com.sun.idm.testing.adapter.compatibility.DeleteMissing)’ passed (4 ms) ’UpdateExisting(com.sun.idm.testing.adapter.compatibility.UpdateExisting)’ passed (4 ms) ’RenameExisting(com.sun.idm.testing.adapter.compatibility.RenameExisting)’ passed (3 ms) ’EnableExisting(com.sun.idm.testing.adapter.compatibility.EnableExisting)’ passed (11 ms) ’DisableExisting(com.sun.idm.testing.adapter.compatibility.DisableExisting)’ passed (5 ms) ’Iterate(com.sun.idm.testing.adapter.compatibility.Iterate)’ passed (22 ms) Tests run: 9, failures: 0, errors: 0, skipped: 0, Time elapsed: 11354 ms

What Happened

The DataProvider supplied an importScript property, which caused the SimulatedCompatibilityConfig.bsh script to run. This script returns an XML string that is imported into the repository as a configuration object. The script specified the necessary items, and the velocity template creates the string.

You can use one of the following methods to debug the import script:

• Use lh console to turn on tracing and then check the generated log files for the script’s return value. For example, type:

  trace 4 com.sun.idm.testing.adapter.CompatibilitySuite

• Use the excludedTests property and exclude each test. No tests run, but the script executes.

This example used beanshell scripting, but you can also use Javascript.

Several beanshell helpers are provided in the sample/compat/beanshell directory to make scripting easier by using the Apache Velocity template engine.

Commented examples are included to help you use the beanshell helpers.

To use the templates, add the following code at the top of your beanshell script:

// import helpers
String wavesetHome = Util.getWavesetHome();

if(wavesetHome != null) {
    if ( wavesetHome.startsWith("file:" ) ) {
        wavesetHome = wavesetHome.substring("file:".length());
    }

    addClassPath(wavesetHome + "./sample/compat/");
}

importCommands("beanshell");

Using the helpers is optional.

When using a script, the only requirement is that the script must return a string containing XML. The script can access any of the parameters that were passed into the CompatibilitySuite using _params.

Where _params can contain any of the following properties.

These properties are not provided in the _params map unless you set them in the properties file or used the -D command from the command line to add these properties to the _params map.

In beanshell, you can use a call to params.get(“parameter_name”) to retrieve these parameters.

If the beanshell script needs to know how the namespace parameter was set so that the script could form the name of the configuration object, the parameter would be retrieved as follows:

String namespace = _params.get("ns");

Example 5: Running Tests from Inside the Web Container

Use the following process to run compatibility tests from inside the web container.

Prepare the Test

Use the following steps to prepare the compatibility tests.

To Prepare the Test

1. Copy ant-junit.jar from Apache ant 1.6.5 to your $WSHOME/WEB-INF/lib directory.

2. Enable the com.sun.idm.testing.adapter.compatibility.CTServlet by uncommenting the following in the web.xml file:

   • Uncomment servlet definition:

     <servlet> <servlet-name>CompatibilityTests</servlet-name> <servlet-class>com.sun.idm.testing.adapter.compatibility.CTServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet>

   • Uncomment servlet mapping:

     <servlet-mapping> <servlet-name>CompatibilityTests</servlet-name> <url-pattern>/servlet/CTServlet</url-pattern> </servlet-mapping>

   ---

   Note –

   • You might have to restart your computer to use the new servlet.

   • The servlet accepts POST requests with certain parameters. Some parameters, such as imported files, allow you to specify multiples.

   ---

3. You can specify the following parameters to the Compatibility Suite:

   Property	Description
   adapter	Classname of the adapter to test
   dp	Name of a custom DataProvider
   excludedTests	Comma-separated list of tests to exclude
   import	Comma-separated list of files to import
   importScript	Comma-separated list of paths to the scripts to execute  Note: These scripts return a string of imported XML.
   includedTests	Comma-separated list of tests to include
   ns	DataProvider namespace
   pass	Plain Text password used to log user on  Note: This password is sent in plain text, which may influence your decision on whether or not to enable the servlet.
   user	Name of user who executes test

   Additional, remote-only parameters include:

   Property	Description
   importXMLText	String containing XML to import
   importScriptText	String containing script to run
   importScriptSuffix	Specify bsh if the script is a beanshell script Specify js if the script is javascript. Note: If you specify multiple scripts to the servlet, the scripts must all be javascript or all beanshell, you cannot specify one of each.

   You can access the servlet through debug/CompatTests.jsp or the command line Java program, CTContainerTest.java.

4. To prepare for running the tests remotely, copy the file idmtesting.jar and the example folders under sample/compat to the remote system.

Execute the Tests

Run the tests from the CompatTests.jsp page

To Execute the Test

1. Open a browser and navigate to your idm instance/debug/CompatTests.jsp. For example,

   http://example.com:8080/idm/debug/CompatTests.jsp

2. To run the example, you must provide the following values:

   Namespace = SimulatedAdapterTests

   Adapter = com.waveset.adapter.SimulatedResourceAdapter

   User Name to Run Test as = configurator

   Password for User to Run Test as = configurator’s password

   Script type = Beanshell radio button

   Import Result of this Script Text = SimulatedCompatibilityConfig.bsh file contents

3. Copy the contents of the SimulatedCompatibilityConfig.bsh file from the sample/compat/example.4 directory and paste them into this text field.

   ---

   Note –

   This script runs Example 4, but you can run the other examples in the same way. The other parameters are available too, but the names are slightly altered in the jsp file.

   ---

   You can also run the compatibility test remotely from a command line Java program called CTContainerTest. The usage is as follows:

   CTContainerTest -url url [-v] [-parm1_name parm1_value e ... -parmx_name parmx_value]

   Where:

   • Parameter names are the same as parameters accepted by the servlet.

   • Parameter values are the same as values accepted by the servlet.

   The servlet does not support the following parameters as a command line argument:

   • importScriptText

     You can use the importLocalScriptFile parameter to send the importScriptText parameter to the servlet. The importLocalScriptFile option reads the contents of the file specified by the parameter value, and submits the content of that file to the servlet with the importScriptText parameter name.

   • importXMLText

     You can use the importLocalXMLFile parameter to send the importXMLText parameter to the servlet. The importLocalXMLFile option reads the contents of the file specified by the parameter value, and submits the content of that file to the servlet with the importXMLText parameter name.

   For more information about the available parameters and their use, run the CTContainerTest program with no arguments, as follows:

   java -cp idmtesting.jar com.sun.idm.testing.adapter.CTContainerTest

   The following examples illustrate different ways to run this command.

   ---

   Note –

   To run these examples in a Windows environment, you must adjust the hostname and port, change the classpath separation character from a colon (:) to a semicolon (;), and change the path separator from a backward slash (/) to a forward slash (\).

   ---

   Running a Compatibility Test Using the Default DataProvider

   java -cp idmtesting.jar:idmcommon.jar com.sun.idm.testing.adapter.CTContainerTest -url "http://host:port/idm/servlet/CTServlet" -adapter com.waveset.adapter.SimulatedResourceAdapter -ns SimulatedAdapterTests -importLocalXMLFile ./example.1/SimulatedCompatibilityConfig.xml -includedTests DeleteMissing

   Running a Compatibility Test with Added Tests

   java -cp idmtesting.jar:idmcommon.jar com.sun.idm.testing.adapter.CTContainerTest -url "http://host:port/idm/servlet/CTServlet" -adapter com.waveset.adapter.SimulatedResourceAdapter -ns SimulatedAdapterTests -importLocalXMLFile ./example.2/SimulatedCompatibilityConfig.xml -includedTests DeleteMissing,EnableExisting,DisableExisting,DeleteExisting,Create

   Running a Compatibility Test After Finishing the Test Configuration

   java -cp idmtesting.jar:idmcommon.jar com.sun.idm.testing.adapter.CTContainerTest -url "http://host:port/idm/servlet/CTServlet" -adapter com.waveset.adapter.SimulatedResourceAdapter -ns SimulatedAdapterTests -importLocalXMLFile ./example.3/SimulatedCompatibilityConfig.xml

   Running a Compatability Test After Executing Beanshell Script

   java -cp idmtesting.jar:idmcommon.jar com.sun.idm.testing.adapter.CTContainerTest -url "http://host:port/idm/servlet/CTServlet" -adapter com.waveset.adapter.SimulatedResourceAdapter -ns SimulatedAdapterTests -importLocalScriptFile ./example.4/SimulatedCompatibilityConfig.bsh