Oracle® Application Server Portal Developer's Guide 10g Release 2 (10.1.4) B14135-03 |
|
![]() Previous |
![]() Next |
The OracleAS Portal Provider Test Suite performs sanity, performance, and unit tests on a Web provider without an installation of OracleAS Portal or Internet access from the provider machine. The following two types of utilities are available to the user in the test suite:
You can download the OracleAS Portal Provider Test Suite from the Oracle Application Server Portal Developer Kit (PDK) page on OTN:
http://www.oracle.com/technology/products/ias/portal/pdk.html
Click Download the JPDK Test Suite.
The provider test page provides a basic sanity test for the provider. It contains a list of portlets, servlet initialization arguments, and the version numbers of the ptlshare
and pdkjava
libraries. The provider test page is the simplest utility available for testing any Web provider. You access the test page by a URL after deploying the enterprise application or Web application on OC4J. You test the Web provider by accessing this URL from a browser:
http://server:port/application_name/providers/provider_name
For example, the PDK-Java comes with a sample application and portlets. The application is encapsulated in a WAR file, which in turn is encapsulated in an EAR file. When you deploy it, OC4J extracts the files and creates a directory structure with the sample portlets under:
ORACLE_HOME/j2ee/home/applications/jpdk
To view the test page for this provider, you would use this URL:
http://server:port/jpdk/providers/sample
When you access the test page, the SOAP servlet validates the XML provider definition, provider.xml
, ensuring that the corresponding provider is well formed. This validation is useful for debugging deployment issues with your provider before attempting to register it with a OracleAS Portal. If you successfully deploy your Web application on OC4J, you receive a success message on the test page.
You can turn the test page on and off by using the JNDI variable oracle/portal/provider/
provider_name
/showTestPage
to true or false. Once a provider is tested and in service you might want to restrict access to the test page. For more information about retrieving and setting JNDI variables, refer to Section 7.2.4, "Using JNDI Variables".
The test harness is a command line utility for unit- and performance-testing your providers without accessing an OracleAS Portal instance. The test harness sends HTTP requests to the target Web provider and records the responses for further analysis. The responses are logged into an XML file. Performance statistics are logged into another file for analysis.
The test harness provides considerable flexibility in the following ways:
You create your own test definition. Based on the information in the test definition, the harness sends requests to the provider. The test definition file is in XML format and lists request instances to send to the target Web provider.
The information returned by the provider is stored in a standard XML file, which makes it easier to understand and analyze.
You can perform load testing of the Web provider.
The test definition file is an XML file that lists the request instances for a particular test. You can optionally subdivide the request instances into request groups within the test definition file. You can include the details of the request instances in the test definition file or refer to a request library XML file that defines the instance details.
In addition to the request instances, the test definition file also includes information about the host and port of the target Web provider and any pre-processors to which it needs to be sent. A pre-processor enables you to include application-specific logic in the request instances at runtime in the test harness. For example, a pre-processor might check the validity of XML in the SOAP messages being sent to the target Web provider. The test harness provides the following three built-in pre-processors:
OracleAS Portal pre-processor
Validation-based caching pre-processor
HMAC (Hashed Message Authentication Checksum) pre-processor
The following sample test definition file illustrates the format and content of the file:
<xml version="1.0" encoding="ISO-8859-1"> <testDefinition version="0.1"> <testDefinition> <defaultHost>machine.name.com</defaultHost> <defaultPort>80</defaultPort> <defaultPath>/jpdk/providers/sample</defaultPath> <property name="portletId" value="1"/> <preProcessorDefinitions> <preProcessor class="oracle.webdb.testharness.preprocessor.PortalPreProcessor"> <name>portal</name> </preProcessor> <preProcessor class="oracle.webdb.testharness.preprocessor.HMACPreProcessor"> <name>hmac</name> <sharedKey>1234567890aBcDeFgHiJ</sharedKey> </preProcessor> </preProcessorDefinitions> <requestGroup id="register"> <description>Carries out necessary registrations</description> <cycles>1</cycles> <threads>1</threads> -- increase the number to load test the Web provider. <requestInstance id="register_provider"> <libraryId>ptl902</libraryId> <definitionId>registerProvider</definitionId> <runs>1</runs> </requestInstance> <requestInstance id="register_portlet"> <libraryId>ptl902</libraryId> <definitionId>registerPortlet</definitionId> <runs>1</runs> </requestInstance> </requestGroup> <requestGroup id="show"> <description>Carries out work necessary to show the portlet</description> ... ... </requestGroup> ... </testDefinition>
The runTest
command invokes the test harness with the specified options using the specified test definition.
runTest options test_definition
Table E-1 describes the command options for runTest
.
Table E-1 runTest Options
Option | Description |
---|---|
-n testname
|
Assigns the specified name to this run. Defaults to a date-time name. |
-g groupId
|
Is a comma separated list of the identifiers of the request groups in the test definition file to be run for this test. To run all groups, specify |
-p perfLogFile
|
Is the name of the performance log file. Defaults to the test name. To disable performance testing, use |
-l resLogFile
|
Is the name of the response log file. Defaults to the test name. |
-v resLogLevel
|
Is the level of response logging (MIN | HEADERS | ALL). Default is ALL. |
-c csvFile
|
Is the name of the response data CSV file. Default is to not generate it. |
-s ctlFile
|
Is the name of the response data ctl file. Default is to not generate it. |
--no-perf |
Switches off all logging of performance data. |
--all-groups |
Runs all groups in the test definition. |
-verbose |
Produces verbose informational logging. |
In order to test Web providers using the test harness, do the following:
Extract the pdktestsuite.zip
file to a convenient location. This will create a directory called pdktest
to which all the test harness files are extracted.
Set an environment variable called PDKTEST_HOME
to point to the location created in the previous step. For example, if you extracted to your D drive, you would now have a directory called D:\pdktest
. Set the value of PDKTEST_HOME
, to D:\pdktest
. The Test Harness provides executable scripts in the bin
directory.
Create a test definition file similar to the one in Section E.2.1, "Test Definition File".
Invoke the runTest
command as described in Section E.2.2, "runTest Command".