Generating and Running Test Cases

Overview

You can use the Oracle API Gateway Explorer test tool to auto-generate SOAP messages, insert security tokens into them, send them to their target Web services, and validate the responses from them. You can view the results for each step of the overall transaction.

A Test Case is used to perform a single test run as described above. The Test Case sets the input message, and then a Test Case policy modifies the message in any way necessary (for example, inserting a SAML authentication assertion) before sending them on to the Web service. The response from the Web Service can then be validated using a series of validation filters.

This topic describes the stages involved in creating and running Test Cases, from auto-generating SOAP messages to validating the responses from the Web service.

Using WSDL to Generate Test Cases

A Web services Description Language (WSDL) file contains the interface definitions for a Web service. It lists the physical address of the service, the operations exposed by the service, together with the rules that determine the formats of the SOAP messages that should be sent to the service.

API Gateway Explorer can use this information to automatically generate a Test Case that can then be used to test every operation exposed by the Web Service. A Test Case is created for each operation defined in the WSDL. A single Test Case Input is created for each Test Case, which contains a sample request for the SOAP operation. The sample SOAP message is automatically populated from the operation definition contained in the WSDL file.

The auto-generated Test Case hierarchy can be summarized as follows:

  • A Test Suite is generated to group together the Test Cases for the operations defined in the WSDL. binding.

  • A Test Case is generated for each operation that has a SOAP binding defined in the WSDL, and that was selected in the WSDL Operations screen of the Load WSDL wizard.

  • Each Test Case contains a single Test Case Input, which consists of an automatically generated sample SOAP message for the operation and an HTTP header containing the corresponding SOAPAction.

Complete the following steps to auto-generate a Test Suite, together with its Test Cases:

Step 1: Load the WSDL

The first step in creating a Test Suite is to load a WSDL file. To do this, select the Load button next to the WSDL field at the top of the API Gateway Explorer interface. The WSDL can be loaded from a file, URL, or a UDDI registry. For more details, see the topic on Retrieving WSDL files from a UDDI registry. Click the Next button when you have specified the WSDL.

Step 2: Select the Operations

On the WSDL Operations screen, select the SOAP operations that you wish to generate Test Cases for by selecting the boxes next to the required operations. Click the Finish button when you have selected the operations. You can see your newly generated Test Suite and its Test Cases in the Navigator panel.

[Note] Note

You can only generate Test Cases for those operations that have a SOAP binding.

Running Test Cases

Having generated some Test Cases using a WSDL file, you can now run them against the Web service.

[Important] Important

You may wish to modify the default parameters that were inserted automatically into the message parts in the SOAP message. You can modify message parts by clicking Test Case Input in the Navigator, and then editing the parts in the SOAP Message panel. You should modify any message parts, if necessary, before running the corresponding Test Cases.

Before running Test Cases you must be in Design Mode. To switch to this mode, click the Design tab on the left in the toolbar.

You can run Test Cases in the following ways:

  • Run a Single Test Case:

    You can run a single Test Case by right-clicking the Test Case in the Navigator and selecting the Run Test Case(s) menu option.

  • Run all Test Cases in a Test Suite:

    You can run all Test Cases belonging to a Test Suite in batch mode by right-clicking the Suite in the Navigator, and selecting the Run Test Case(s) menu. option.

  • Run all Test Cases in the Workspace:

    If you wish to run all Test Suites (and their Test Cases), you can right-click the top-level Workspace node in the Navigator, and select the Run Test Case(s) menu option.

Viewing the Results

When any Test Cases are run (individually or in batch mode), the results are displayed in the Results Mode of the API Gateway Explorer interface. You can review results for individual Test Cases by clicking the Tests tab at the bottom of the Results tab.

The results are listed according to the name of their Test Suite. The Test Suite node can be expanded to display the results of each of the Test Cases. You can click the Test Case node to display the response from the Web service for the corresponding SOAP operation.

[Note] Note

You can format the SOAP response into a more user-friendly format by selecting the Auto Format XML Response box in the Auto Format Response section of the global Preferences dialog. This is available from the Window > Preferences top-level menu.

When you expand each of the Test Cases you can see that a number of steps were performed. For a default auto-generated Test Suite, these steps are called Rewrite URL, Static Router, and Connection. These steps are called filters, and can be configured for each Test Case by clicking the Test Case node in the Navigator view.

You can export all results currently on display in the table in the Results tab by selecting the Export Results option in the drop-down menu beside the triangular green Run button in the toolbar. When this option is selected, the current results set is written out to an XML file. You can import this results set again by selecting the Import Results option, and browsing to the XML file that you exported the results to.

You can also select Clear Results to clear the table completely. Make sure you have saved any results that you may want to reuse before clearing the Stress Test Results table.

Configuring Individual Test Cases

To see the filters that comprise an individual Test Case, click the Test Case node in the Navigator tree. The policy of filters that make up the Test Case is displayed in the Design Mode in the main panel of the API Gateway Explorer interface.

By default, any Test Case that was auto-generated from a WSDL file contains instances of the following filters:

  • Rewrite URL

  • Static Router

  • Connection

These filters are automatically populated with the address of the Web service defined in the WSDL file. The auto-generated message from the Test Case Input is passed into this policy, which is responsible for routing the message on to the configured destination.

You can add several other filters to the policy to enable you to create powerful and complex tests. Several categories of filters are located on the right-hand side of the API Gateway Explorer interface.

To add a filter to a policy, drag and drop the filter from the palette on to the policy. You can drag a filter on to a green arrow on a previously configured policy to insert the filter at that point in the policy.

Filters can be joined together using the Success Path (green) and Failure Path (red) arrows, which are located just above the filter palette. If a filter fails (for example, schema validation fails), the failure path is followed. However, if a filter runs successfully (for example, schema validates successfully), the success path is followed.

If you want to validate the response message from the Web service, you must place the validating filters after the Connection filter in the policy. This filter is responsible for making the connection out to the Web service, sending the request, and receiving the response. Therefore, any filters that are placed after it in a policy are effectively acting on the response message.

You can mark a filter as the starting point of the policy by right-clicking the filter in the policy, and selecting the Set as Start menu option.

For more information on the filters available in API Gateway Explorer, see the Message Filters section in the product documentation. You can find a links to the main categories of filters from the main index page of the documentation.