Developing integration tests

You can create and run unit tests to validate the operation of your IBM® App Connect Enterprise flows and message flow nodes.

Before you begin

Read the following topics:

About this task

You can create and run unit tests while you are developing your message flows and nodes, or you can create and run tests for flows that have already been deployed, by generating tests in bulk from messages that were recorded as they passed through a message flow.

The tests that you use to validate the message flows and nodes are written in Java and are stored in App Connect Enterprise test projects. You can write the tests by using a text editor, a source code editor, or a Java IDE such as the IBM App Connect Enterprise Toolkit. The simplest way to create a unit test for a message flow node is to use the Create Test Case wizard in the Toolkit, as described in Developing integration tests by using the IBM App Connect Enterprise Toolkit. For information about generating tests from recorded messages, see Generating tests from recorded messages in a message flow.

To test a message flow node, an input message assembly is required to invoke the node, and the contents of the output message assembly are examined to determine whether the operation of the message flow node was successful. A message assembly is an object that is used to represent an instance of a message at a given point in time as it is being processed by a message flow. The message assembly contains the message headers and payload (which can be XML, JSON, DFDL or BLOB data), together with the environment tree, the local environment tree, and the exception list tree. The contents of the message assembly are accessed and modified by each message flow node as the message is processed.

A set of Java classes in the supplied IntegrationTest.jar file provides a mechanism for creating, building, testing and comparing message assemblies and their contents.

You can record messages as they pass through a message flow, and each recorded message is stored as an .mxml file, which is a serialized form of a message assembly. These .mxml files can then be used by unit tests, to validate the operation of the message flow nodes and flows. You can record the messages and create the serialized message assembly files either by setting the RecordAllMessages property in the integration server's server.conf.yaml file, or by opening the flow in the IBM App Connect Enterprise Toolkit and invoking the Create Test Case wizard on the message flow node in the Flow Exerciser.

You can control the level of granularity in your testing by creating integration tests for a single message flow node, a sequence of message flow nodes (such as a subflow or callable flow), or a whole message flow:
  • Testing a message flow node:

    You can test the operation of an individual node in a message flow, in isolation from the rest of the nodes in the flow. An input message is passed into the message flow node, and the operation of the node is validated by comparing the output message against the expected output, together with any secondary actions such as updates to a database or any exceptions thrown. The tests pass messages directly to the message flow node that is being tested, rather than through the input node of the flow; this means that the owning message flow must be deployed to the integration server and initialized, but it does not need to be running.

  • Testing a partial message flow:

    You can test a subflow or sequence of nodes in a message flow without testing the whole flow. An input message is passed into the first message flow node in the sequence and it is propagated through the flow until it reaches a defined stop point or the end of the flow. The tests pass messages directly to the first message flow node in the sequence, rather than through the input node of the flow; this means that the message flow being tested must be deployed to the integration server, but it does not need to be running.

    The success of the test can be established by validating the route of the message as it propagates through the flow, and the contents of the message at any point throughout the flow, as well as any secondary actions such as updates to a database or exceptions thrown.

    When testing a sequence of node nodes, you might need to alter the behavior of some nodes in the sequence to avoid accessing unavailable resources or to force the execution to follow a particular path.

  • Testing a whole message flow:

    You can test a whole message flow by invoking the message flow using its published interfaces, such as HTTP, MQ, File, and so on. The input nodes are typically invoked using their native transport interfaces supported by the input node called from the code in the test project. The message flow is invoked through the input node, which means that the message flow must be deployed and running in order for the tests to run.

    Like partial message flow testing, the test can validate the route of the message as it propagates through the flow, in addition to the contents of the message at any point throughout the flow. The test can also alter the behavior of nodes in the flow by substituting responses or by modifying behavior.

For information that you need to know before you start developing integration tests, see Integration testing overview.

Procedure

Read the following sections to learn more about developing and running integration tests:

For demonstrations of some of the App Connect Enterprise integration testing capabilities, see the following videos: