Test execution

In Rational® Integration Tester, tests generally consist of one or more inputs into the systems under test (SUT), and then validation of results and side effects. Data from one step of a test can be used to feed the next step. Rational® Integration Tester is built for testing, so every test step can be validated without scripting.

The test execution process consists of the following steps:

Create test steps that include a send message action and a receive message action.
Set the expected message outcome in the receive message action.
Trigger the send message action that is, sending the message or messages to the SUT.
Capture the reply from the SUT.
Validate the received message against the expected message and point out any differences.

Each project has multiple environments to represent environments, such as development and testing. Every environment has different server end points that are new physical entities in the physical view. There is always the chance of user error in binding these properties.

Consider the following points:

In the environment editor, double-check that the logical components are mapped to the correct physical components for the respective environment.
Always remember to switch to the correct environment before you run tests because each project can have multiple development and test environments.

If you want to retrieve historical results, you must set up a results database for your projects. This capability is useful for the test management process because a test manager can view the results of previous executions without requiring knowledge of Rational® Integration Tester.

Before you run the test suites, you need to make sure that you are communicating with the right components and whether these components represent the live system or virtualized components.

Note: Double-check whether the execution calls are satisfied by the live system (that is, the test live system, not a production system) or stubbed system.

Sometimes, testing complex business processes can produce large logs especially if a test fails due to a server error while you are running tests multiple times. Consider logging data to log files instead of logging on the console so that the logs can be saved and make it easier to point out the issues.

If the requirement is to stop the execution of the test suite if even one test fails, stopping the test can be configured in the test suite settings. This is done when the next test has a dependency on the result of the previous test. If test suites need to be run regularly, consider using the scheduling facility or continuous integration.

Rational® Integration Tester has a strong validation feature. Every test that is created can have an expected message and this expected message is compared with the actual message for every execution.

While creating tests you can ensure the assert tag is used properly to enable and disable validations on the message fields. This provides more flexibility for deciding which fields can be included for validation.

In many cases, the reply message has fields that have dynamic values. For every execution, these values keep changing and they might be difficult to validate. Examples of this are time stamps and message IDs. If test execution fails due to validation errors because of dynamic values, open the Message Differences window by clicking the error on the console.

Use regular expressions wherever possible. In addition, Rational® Integration Tester automatically identifies the patterns that are based on the value of field in the current message, which reduces the effort required to create a regular expression from scratch.