4.9.2. Creating or updating test cases

You can create or update test cases from any test cases list, or from message record details. See Accessing test cases page for more details.

When you edit a test case, the following information will be editable.

Identification

The first section is about identifying your test case. 

As for all other elements, a Name is important for you to recognize this test case later. We strongly recommend that you give meaningful names to your tests to identify them later easily. "No invoice line" is probably clearer than "Test case 17".  The field Description allows you to add any other information that you want to retain about your test case.

If you need a unique identifier for a test case, as for example to communicate to some colleague or to the Babelway support, you can also show the column Id in all the test cases grids.

In all cases, all the fields in this section are only useful for you, to identify easily your test cases, but these fields will not affect how the test case behave.

Tested item

The second section is about to which transformation of channel this test cases relates.

In the huge majority of the cases, a test case should be related to a Transformation, like shown on the above screenshot. By doing this, the test case will be automatically visible in all the channels that use this transformation. Also, there are almost no requirement to be able to run these channels. You will for example be able to run the test as soon as you have defined a MDIn, a transform and a MDOut. There is no need for the channel to be really complete.

The other option is to link the test case to a Channel. This is only meaningful if you want to test not only how the MessageDefinitions and the Transformation (including all the extra processings) are behaving, but if you also want to test the routings of your channels. These channel test cases will indeed also execute all the routings, and fail if one message would be redirected to another channel that the one being tested. This comes at the price of the execution being slower, and requiring that all elements of the channel (like gateways and routings) and of all related channels (accessible through any routing) are fully defined before they can be executed.

Input

The third section is about the Input of the test case. The purpose of this section is to define which message will be submitted to the system for this test.

The main parameter is here the message IN. It is exactly the input file as a normal gateway would have received it from the source partner.

The other parameter allows to also associate some Metadata to this content. As the test case will only test a single channel, but not execute its gateways or any potential previous channel in your flow, it is needed to define here the metadata that are required by your channel in its input, but are expected to come from some prior processing. Here are a few examples : 

• Some Gateway INs will add some system metadata to the message. For example, a Email Gateway IN will add some information like the subject of the email, the sender or receiver email addresses, ... If your processing relies on this data, you need to set them there, because the test case will not receive a real email, and will therefore not define these fields during the test.
• Sometimes, a channel is not the first channel in some complex flow, and is relying on some user metadata that have been set by the previous channels. Again, as we are here only testing this single channel, it is needed to tell the system which metadata have to be defined when starting the execution of the message.

Success conditions

This last section lists all the assertions that you expect to be satisfied by the message at the end of its processing.

For example, you can expect that the message ends in Success or Error, that the output message is the expected one (with all the fields correctly filled), that some metadata has correctly been calculated, ... 

Success conditions are explained in details in the dedicated section.