The integration test client is the designated WebSphere® Integration
Developer tool for testing modules and components. When you open the integration
test client, a default test configuration is automatically generated. This
default test configuration is often all you need to perform your test activities.
In this topic, you learn how to test an operation using the default
test configuration. However, before you can run any test, you need
to ensure that the module that contains the interface operation that you want
to test has at least one component either with or without an implementation
or implementation type.
To illustrate how a test is run using the default test configuration,
an example module named NewOrderEntry is used. The NewOrderEntry module is
a basic order processing application that has three components: OrderEntry,
POValidation, and Inventory. The OrderEntry component accepts your order and
calls the POValidation component to determine whether the specified purchase
order is valid. If the purchase order is valid, the Inventory component creates
the order and automatically adjusts the current availability of any ordered
items.
To run a test with the default test configuration:
- Open your module in the assembly editor. The example module NewOrderEntry
is shown in the following figure of the assembly editor:

- If you decide to make any changes to the module in the assembly
editor, ensure that you press Ctrl-S to save your changes.
- In the assembly editor canvas, complete one of the following steps:
- If you want to test your entire module, right-click an empty portion
of the canvas and select Test Module. (By default,
any unimplemented components and unwired references in the module will be
emulated.)
- If you want to test a subset of components in your module, use the Ctrl key
to select the components in the set, then right-click one of the selected
components and select Test components. (By default,
any unselected components in the module will be emulated regardless of whether
they are implemented or not.)
- If you want to test a single component in your module, right-click
the component and select Test component. (By default,
all other components in the module will be emulated regardless of whether
they are implemented or not.)
The integration test client opens and displays an Invoke event
in the Events area, as shown in the figure below:

An Invoke event is
automatically generated whenever you start the integration test client. It
is an interactive event, which means that you must manually select an operation
and specify values for the operation before the test can continue, as described
in the following steps.
- In the Detailed Properties area of the integration
test client, complete the following steps:
- In the Configuration field, ensure that
the correct test configuration is selected. A default test configuration is
automatically created whenever you open the integration test client. If you
did not open the integration test client by loading a test configuration that
you saved earlier, the default test configuration will already be selected
in the Configuration field.
- In the Module field, ensure that the
correct module is selected. If you opened the integration test client by selecting
a module, this module will already be selected in the Module field.
- In the Component field, ensure that the
component is selected that contains your interface operation.
- In the Interface field, ensure that the
interface is selected that contains your operation.
- In the Operation field, ensure that the
operation is selected that you want to test.
The above figure shows the detailed properties that are selected in
preparation for invoking the takeOrder operation, which is contained in the
Order interface of the OrderEnty component.
- In the value editor, specify values for the selected operation
by positioning your cursor in the Value column and
typing in values for each attribute in the editor. For example, the figure
below shows that the value clothes has been specified
for the description attribute:

If you
want to specify values for arrays, right-click the name of each array attribute
in the Name column and select Add Element to
open the Add Element dialog box, then specify a value for the selected attribute
in the Enter the number of new elements to add field
and click OK. For example, the figure
below shows that the value 5 has been specified for
the quantity attribute within the element in the items array:

- Click Continue. Depending on the current
deployment state of your module, the Deployment Location wizard opens, as
shown in the figure below:

In the
Deployment Location wizard, WebSphere Process Server v6.0 always
appears as a selectable deployment location. However, if you are testing a
mediation module, WebSphere ESB Server v6.0 will also
appear as a selectable deployment location in the Deployment Location wizard.
Similarly, if your module contains only Java components or it contains J2EE
components that are all unimplemented, Eclipse 1.4 JVM will
appear as a selectable deployment location. Note that if you have more than
one module in your test configuration, the Deployment Location wizard will
be preceded by a different deployment wizard that asks you to select a specific
server for each module.
- Complete one of the following steps:
- If your module contains at least one component that is not a Java™ component
or if you want to test a set of interacting modules, ensure that WebSphere
Process Server v6.0 is selected in the Deployment location list
box. (This is the designated server for running SCA applications, BPEL business
processes, human tasks, transition tables, business rules, selectors, and
other resources. You can also use this server for running mediation flows
contained in mediation modules.)
- If your module is a mediation module, you can select WebSphere
ESB Server v6.0. (Generally, if you intend to eventually deploy
your mediation module to a WebSphere Enterprise Service Bus production server,
then WebSphere ESB Server v6.0 is a good choice. However,
if you intend to eventually deploy your mediation module to a WebSphere Process
Server production server, then you may want to select WebSphere
Process Server v6.0.)
- If your module only contains Java components and you don't want to test
a set of interacting modules, or if your module contains J2EE resources but
none of the components are implemented, you can select Eclipse
1.4 JVM. (The main advantage to choosing the Eclipse JVM is that
it starts more quickly than WebSphere Process Server or WebSphere Enterprise
Service Bus. However, once started, the Eclipse JVM, WebSphere Process Server, and WebSphere
Enterprise Service Bus all provide similar test performance.)
- In the Mode drop-down list, select either Run or Debug to
start the server in Run or Debug mode. (If the server is already running in
one of these modes, the Mode drop-down list will show
the current server mode and it will be disabled.)
- Click Finish. The server is started (if
it is not already running) and the module is deployed to the server, which
enables the invocation of your operation to continue. In the integration test
client, the Events area rapidly displays several events that together form
an execution trace of your test. If a manual emulator is encountered, the
test pauses at a manual Emulate event. If no manual emulator is encountered,
the test will complete and pause at a Return event. When a test is run on
the takeOrder operation of the example module OrderEntry, the test pauses
at a manual Emulate event (because the POValidation component has no implementation
and is being emulated), as shown in the following figure:

- Before you specify values for your manual Emulate event, complete
the following steps to familiarize yourself with the detailed properties for
each event that was generated before the manual Emulate event. The actual
events generated before the manual Invoke event will vary depending on the
operation that you chose to test.
- In the Events area, select the Invoke event
under the Started event. In the Detailed Properties
area, you can view the properties and the input parameter values that were
passed to your operation. For example, the input parameter values that were
passed to the takeOrder operation are shown in the following figure:

- In the Events area, select the monitor Request event
(if any exists). In the Detailed Properties area, you can view the request
that was monitored as it flowed over the wire between components. For example,
the request that flowed over the wire from the OrderEntry component to the
POValidation component is shown in the following figure:

- In the Events area, select the manual Emulate event
where the test is currently paused, as seen in the following figure:

A manual
emulation event is automatically generated in the following situations:- You have chosen to test an entire module and the integration test client
has encountered an unimplemented component.
- You have chosen to test a set of components or a single component in a
module, which means that any other unselected components in the module are
automatically emulated regardless of whether they are implemented or not.
Much like a manual Invoke event, a manual Emulate event is an interactive
event that requires you to take some action before the test can continue.
However, unlike a manual Invoke event, a manual emulation event requires you
to either specify output parameter values or select an exception to throw.Note: The
flow of control through an emulated component or reference may be contained
in a transaction with a specific timeout value. If you do not specify the
value in the allotted time, the transaction may time out and cause the invocation
to fail with a timeout exception.
- Complete one of the following steps:
- If you want to pass output parameter values rather than throw
an exception, specify the output values in the Value column
of the Output parameters value editor. For example,
the figure below shows the output value of false:

- If you want to throw an exception, select the exception that
you want to throw from the Throw exception drop-down
list, then specify some values in the Output parameters values
editor. The Throw exception list box is shown in the
figure below:

Note that the only exceptions that can
be thrown are those that are specified as faults in the interface or in the throws clause
of a Java interface.
- Click Continue to continue the invocation
of the operation. If you chose to pass some output parameter values rather
than to throw an exception, the Events area displays a Return event
and the test completes. In the Detailed Properties area, the results of the
operation are displayed. For example, in the following figure, the value editor
shows the results that were returned for the takeOrder operation:

A Return
event is automatically generated when the integration test client returns
the results of the operation. A Return event is an informational event, which
means that there is no action for you to take other than to view the results
that were returned.
- To familiarize yourself with the detailed properties for a monitor
Response event, select the monitor Response event (if
any exists). In the Detailed Properties area, you can view the response that
was monitored as it flowed over the wire between components. For example,
the response that flowed over the wire from the POValidation component to
the OrderEntry component is shown in the following figure:

- Complete one of the following steps:
- If you want to rerun the operation and either specify new output
parameter values or select an exception to throw for the manual Emulate event,
right-click the manual Invoke event in the Events area and select Rerun.
- If you want to rerun the operation using the same output parameter
values or exception that you used earlier for the manual emulator, right-click
the manual Invoke event in the Events area and select Rerun with
Auto Emulate.
- If you want to select a different operation for testing, generate
a manual Invoke event in the Events area by clicking the Invoke icon
.
Then select an operation, specify some input parameter values, and invoke
the operation as described at the beginning of this topic.
- Press Ctrl-S at any time to save the current
execution trace to an execution trace file. Information about working with
an execution trace is found in the topic "Managing execution traces."