Getting started with the integration test client

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:

  1. Open your module in the assembly editor. The example module NewOrderEntry is shown in the following figure of the assembly editor:
    Picture of the OrderEntry module open in the assembly editor
  2. If you decide to make any changes to the module in the assembly editor, ensure that you press Ctrl-S to save your changes.
  3. 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:
    Picture of the integration test client
    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.
  4. In the Detailed Properties area of the integration test client, complete the following steps:
    1. 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.
    2. 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.
    3. In the Component field, ensure that the component is selected that contains your interface operation.
    4. In the Interface field, ensure that the interface is selected that contains your operation.
    5. 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.
  5. 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:
    Picture of the value editor for the initial request parameters
    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:
    Picture of the value editor for the initial request parameters
  6. Click Continue. Depending on the current deployment state of your module, the Deployment Location wizard opens, as shown in the figure below:
    Picture of the Deployment Location wizard
    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.
  7. 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.)
  8. 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.)
  9. 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:
    Picture of the integration test client paused at a manual Emulate event
  10. 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.
    1. 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:
      Picture of the integration test client with an Invoke event selected
    2. 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:
      Picture of the integration test client with an Request Monitor event selected
  11. In the Events area, select the manual Emulate event where the test is currently paused, as seen in the following figure:
    Picture of the integration test client paused at a manual emulation event
    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.
  12. Complete one of the following steps:
    1. 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:
      Picture of the value editor for the output parameters
    2. 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:
      Picture of the Throw Exception drop-down list
      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.
  13. 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:
    Picture of the integration test client stopped at a response event
    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.
  14. 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:

  15. Complete one of the following steps:
    1. 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.
    2. 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.
    3. If you want to select a different operation for testing, generate a manual Invoke event in the Events area by clicking the Invoke icon Picture of the Invoke icon. Then select an operation, specify some input parameter values, and invoke the operation as described at the beginning of this topic.
  16. 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."

Feedback
(C) Copyright IBM Corporation 2005, 2006. All Rights Reserved.