After writing a custom resource adapter, you must test the validity of that adapter. In particular, you must test the connection to the resource.
Topics covered in this section include:
Use the following steps to unit-test the validity of a custom adapter (in particular, to test the connection to the resource):
Save the adapter.
Run unit tests on that adapter from your own machine.
Load the adapter into Waveset.
Test the adapter in Waveset, as follows:
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:
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.
Open a command window.
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.
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.
This example illustrates how to run compatibility tests on a SimulatedResourceAdapter using the default DataProvider.
Use the following steps to prepare the compatibility tests.
Set up the following files:
sample/compat/example.1/example.properties
sample/compat/example.1/SimulatedCompatibilityConfig.xml
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.
Before executing the example, copy ant-junit.jar from Apache ant 1.6.5 to your $WSHOME/WEB-INF/lib directory.
Use the following steps to execute the compatibility tests.
Open a command window.
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 |
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.
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.
Use the following steps to prepare the compatibility tests.
Set up the following files:
sample/compat/example.2/example.properties
sample/compat/example.2/SimulatedCompatibilityConfig.xml
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.
Before executing the example, copy ant-junit.jar from Apache ant 1.6.5 to your $WSHOME/WEB-INF/lib directory.
Use the following steps to execute the compatibility tests.
Open a command window.
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 |
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.
In this next example, you finish the test configuration.
Use the following steps to prepare the compatibility tests.
Set up the following files:
sample/compat/example.3/example.properties
sample/compat/example.3/SimulatedCompatibilityConfig.xml
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.
Before executing the example, copy ant-junit.jar from Apache ant 1.6.5 to your $WSHOME/WEB-INF/lib directory.
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> |
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> --> |
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.
Use the following steps to execute the compatibility tests.
Open a command window.
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 |
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.
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 compatibility test to execute with a beanshell script
Set up the following files:
sample/compat/example.4/example.properties
sample/compat/example.4/SimulatedCompatibilityConfig.bsh
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.
Before executing the example, copy ant-junit.jar from Apache ant 1.6.5 to your $WSHOME/WEB-INF/lib directory.
Execute the compatibility tests as follows:
Open a command window.
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 |
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.
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 |
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");
Use the following process to run compatibility tests from inside the web container.
Use the following steps to prepare the compatibility tests.
Copy ant-junit.jar from Apache ant 1.6.5 to your $WSHOME/WEB-INF/lib directory.
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> |
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.
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.
To prepare for running the tests remotely, copy the file idmtesting.jar and the example folders under sample/compat to the remote system.
Run the tests from the CompatTests.jsp page
Open a browser and navigate to your idm instance/debug/CompatTests.jsp. For example,
http://example.com:8080/idm/debug/CompatTests.jsp
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
Copy the contents of the SimulatedCompatibilityConfig.bsh file from the sample/compat/example.4 directory and paste them into this text field.
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.
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 |
This section describes the following methods for testing the resource object:
You can confirm the configuration of your resource by viewing the raw XML in the repository.
Log into the Administrator user interface.
Open the Waveset Debug pages by entering http://host:port/idm/debug in the browser.
Choose Resource from the pull-down menu located next to the List Objects button.
Click the List Objects button.
The List Objects of Type: Resource page displays with a list of all resource adapters and Active Sync-enabled adapters.
All resource adapter and Active Sync-enabled adapter classes are based on existing Waveset Resource classes.
Find the resource object you want to see.
To view the resource object, click the View link.
To edit the resource object, click the Edit link.
When you are finished, click Back.
You can use the Find Resources and List Resources pages in the Waveset Administrative interface to test your implementation of a resource object.
Select Resource > List Resource to confirm the following performance characteristics.
Table 10–32 List Resource Performance Characteristics
Select Resource > Find Resources to confirm the following performance characteristics.
Table 10–33 Find Resources Performance Characteristics