41 Automating Testing of SOA Composite Applications

This chapter describes how to create, deploy, and run test cases that automate the testing of SOA composite applications. Test cases enable you to simulate the interaction between a SOA composite application and its web service partners before deployment in a production environment. This helps to ensure that a process interacts with web service partners as expected by the time it is ready for deployment to a production environment.

41.1.1 Test Cases Overview

The test framework supports testing at the SOA composite application level. In this type of testing, wires, service binding components, service components (such as BPEL processes and Oracle Mediator service components), and reference binding components are tested.

41.1.2 Test Suites Overview

Test suites consist of a logical collection of one or more test cases. Each test case contains a set of commands to perform as the test instance is executed. The execution of a test suite is known as a test run. Each test corresponds to a single SOA composite application instance.

41.1.4 Assertions Overview

Assertions enable you to verify variable data or process flow. You can perform the following types of assertions:

Entire XML document assertions:

Compare the element values of an entire XML document to the expected element values. For example, compare the exact contents of an entire loan request XML document to another document. The XMLTestCase class in the XMLUnit package includes a collection of methods for performing assertions between XML files. For more information about these methods, visit the following URL:

41.2 Introduction to the Components of a Test Suite

This section describes and provides examples of the test components that comprise a test case. Methods for creating and importing these tests into your process are described in subsequent sections of this chapter.

41.2.1 Process Initiation

You first define the operation of your process in a binding component service such as a SOAP web service. Example 41-1 defines the operation of initiate to initiate the TestFwk SOA composite application. The initiation payload is also defined in this section:

Two message files, loanApplication.xml and creditRatingFault.xml, are invoked in this emulation. If the loan application request in loanApplication.xml contains a social security number beginning with 0, the creditRatingFault.xml file returns the fault message shown in Example 41-3:

41.2.3 Assertions

You create assertions to validate an entire XML document, a part section of a message, a nonleaf element, or a leaf element at a point during SOA composite application execution. Example 41-4 instructs Oracle SOA Suite to ensure that the content of the customername variable matches the content specified.

41.2.4 Message Files

Message instance files provide a method for simulating the message data received back from web service partners. You can manually enter the received message data into this XML file or load a file through the test mode of the SOA Composite Editor. For example, the following message file simulates a credit rating result of 900 returned from a partner:

Enter a test suite name (for example, OrderBookingMainTestsuite of the Fusion Order Demo).

Click OK.

The Create Composite Test dialog appears.

Enter a test name (for this example, NoErrorSanityTest of the Fusion Order Demo is entered) and an optional description. This description displays in the Description column of the Test Cases page of the Unit Tests tab in Oracle Enterprise Manager Fusion Middleware Control.

Click OK.

This action creates a test named NoErrorSanityTest.xml in the Application Navigator, along with the following subfolders:

componenttests

This folder is not used in 11g Release 1.

includes

This folder is not used in 11g Release 1.

messages

Contains message test files that you load into this directory through the test mode user interface.

tests

Contains NoErrorSanityTest.xml.

A NoErrorSanityTest.xml folder also displays in the Structure window. Figure 41-4 provides details. This indicates that you are in the test mode of the SOA Composite Editor. You can create test initiations, assertions, and emulations in test mode. No other modifications, such as editing the property dialogs of service components or dropping service components into the editor, can be performed in test mode.

Do not edit the filelist.xml files that display under the subfolders of the testsuites folder. These files are automatically created during design time, and are used during runtime to calculate the number of test cases.

You cannot create test suites within other test suites. However, you can organize a test suite into subdirectories.

41.4 Creating the Contents of Test Cases

Test cases consist of process initiations, emulations, and assertions. You add these actions to test cases in the test mode of the SOA Composite Editor. You create process initiations to initiate client inbound messages into your SOA composite application. You create emulations to simulate input or output message data, fault data, callback data, or all of these types that your SOA composite application receives from web service partners. You create assertions to validate entire XML documents, part sections of messages, nonleaf elements, and leaf elements as a process is executed.

41.4.1 How to Initiate Inbound Messages

To initiate inbound messages:

You must first initiate the sending of inbound client messages to the SOA composite application.

Go to the SOA Composite application in test mode.

Double-click the service binding component shown in Figure 41-7 (for this example, named initiate).

The SOA composite application in the SOA Composite Editor is refreshed to display in test mode. This mode enables you to define test information.

Double-click the wire of the SOA composite application area to test. For the example shown in Figure 41-10, the wire between the LoanBroker process and the synchronous CreditRating web service is selected.

An example of a simulated fault message from a web service partner that you enter manually or load from a file is shown in Section 41.2.2, "Emulations."

Click OK.

41.4.5 How to Create Assertions

To create assertions:

You perform assertions to verify variable data or process flow. Assertions enable you to validate test data in an entire XML document, a part section of a message, a nonleaf element, or a leaf element as a process is executed. This is done by extracting a value and comparing it to an expected value.

Select the type of assertion to perform at the top of the dialog, as shown in Table 41-5. If the operation supports only input messages, the Assert Input button is enabled. If the operation supports both input and output messages, the Assert Input and Assert Output buttons are both enabled.

Table 41-5 Assertion Types

Type

Description

Assert Input

Select to create an assertion in the inbound direction.

Assert Output

Select to create an assertion in the outbound direction.

Assert Callback

Select to create an assertion on a callback.

Assert Fault

Select to assert a fault into the application flow.

See the section shown in Table 41-6 based on the type of assertion you want to perform.

41.4.5.1 Creating Assertions on a Part Section, Nonleaf Element, or Entire XML Document

To create assertions on a part section, nonleaf element, or entire XML document:

This test compares the values to the expected values.

Note:

If the message contains multiple parts (for example, payload1, payload2, and payload3), you must create separate assertions for each part.

Click Browse to select the target part section, nonleaf element, or entire XML document to assert.

The Select Assert Target dialog appears.

Select a value, and click OK. For example, select a variable such as payload to perform a part section assertion.

Figure 41-16 shows this dialog. While this example shows how to perform a part section assertion, selecting LoanBrokerRequestMessage is an example of an entire XML document assertion and selecting loanApplication is an example of a nonleaf assertion.

xml-identical: Used when the comparison between the elements and attributes of the XML documents must be exact. If there is any difference between the two XML documents, the comparison fails. For example, the comparison fails if one document uses an element name of purchaseOrder, while the other uses an element name of invoice. The comparison also fails if the child attributes of two elements are the same, but the attributes are ordered differently in each element.

xml-similar: Used when the comparison must be similar in content, but does not need to exactly match. For example, the comparison succeeds if both use the same namespace URI, but have different namespace prefixes. The comparison also succeeds if both contain the same element with the same child attributes, but the attributes are ordered differently in each element.

In both of these examples, the differences are considered recoverable, and therefore similar.

For more information about comparing the contents of XML files, see the XMLUnit web site:

pattern-match: Compares a regular expression pattern (for example, [0-9]*). Java Development Kit (JDK) regular expression (regexp) constructs are supported. For example, entering a pattern of ab[0-9]*cd means that a value of ab123cd or ab456cd is correct. An asterisk (*) indicates any number of occurrences.

Assert Value

Enter the value you are expecting. This value is compared to the value for the assert target.

41.4.6 What You May Need to Know About Assertions

When a test is executed, and the response type returned is different from the type expected, the assertion is skipped. For example, you are expecting a fault (RemoteFault) to be returned for a specific message, but a response (BpelResponseMessage) is instead returned.

As a best practice, always assert and emulate the expected behavior.

41.5 Deploying and Running a Test Suite

After creating a test suite of test cases, you deploy the suite as part of a SOA composite application. You then run the test suites from Oracle Enterprise Manager Fusion Middleware Control.