E Oracle Portal Provider Test Suite

The Oracle Portal Provider Test Suite performs sanity, performance, and unit tests on a Web provider without an installation of Oracle Portal or Internet access from the provider machine. The following two types of utilities are available to the user in the test suite:

More on OTN

You can download the Oracle Portal Provider Test Suite from the Oracle Portal Developer Kit (PDK) page on Oracle Technology Network (OTN):

http://www.oracle.com/technology/products/ias/portal/pdk.html

From the Oracle Portlet Developer Kit (PDK) home page, select Download the PDK-Java TestSuite.

E.1 Provider Test Page

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 Oracle WebLogic Server. 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, Oracle WebLogic Server extracts the files and creates a directory structure with the sample portlets under:

MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\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 Oracle Portal. If you successfully deploy your Web application on WLS, 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".

E.2 Test Harness

The test harness is a command line utility for unit- and performance-testing your providers without accessing an Oracle 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.

E.2.1 Test Definition File

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:

  • Oracle 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>

E.2.2 runTest Command

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 --all-groups.

 
-p perfLogFile

Is the name of the performance log file. Defaults to the test name. To disable performance testing, use --no-perf.

 
-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.

E.2.3 Running a Test with Test Harness

In order to test Web providers using the test harness, do the following:

  1. Extract the pdktestsuite.zip file to a convenient location. This will create a directory called pdk\testsuite\pdktest to which all the test harness files are extracted.

  2. 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:\pdk\testsuite\pdktest. Set the value of PDKTEST_HOME, to D:\pdk\testsuite\pdktest. The Test Harness provides executable scripts in the bin directory.

  3. Create a test definition file similar to the one in Section E.2.1, "Test Definition File".

  4. Invoke the runTest command as described in Section E.2.2, "runTest Command".