1. Babelway
  2. Babelway User Guide
  3. Chapter 4. Manage & Build

4.9.3. Success conditions

The success conditions of a test case are the conditions that must be satisfied by the message, at the end of its execution, so that the test can be considered as a success.

This page lists all the available success conditions : 

Also, don't hesitate to contact us if you would like to see additional checks made available for your tests.

 

Expected status

This condition says if the message processing should end in Success or in Error for this test case.

It is here important to understand the difference between the "Message status", and the "Test case status". Here, we are defining that the test case is successful (meaning that the system behaves as expected) if the message has terminated in the expected status. 

In many cases, we expect that the message ends in Success, but when testing error cases, we can wish that the processing ends in Error with the proper error message. For example, if we have a channel that process pdfs, we can want to test that non-pdfs input files will properly be rejected. In that case, we expect that the Message status is "Error" so that the test is considered a success.

 

 

 

Expected message out - binary comparison

This check tells that the message out must be exactly the one that you provide.

This is very convenient if the output file for a given input file will always be exactly the same.

 

Expected message out - textual comparison

This check also tells that the message out must be similar to the one that you provide but, unlike the binary comparator, it is able to manage some advanced comparison rules, for fields that are unpredictable, like unique ids or timestamps.

For example, you will be able to tell the system that the output file must be exactly like the one you provided, except for the fields date/time and the field uniqueId, for which you don't care about the content in the comparison. Or that you don't care about the real value in the time field, but that it must have the format hh:mm, which hh and mm being integers between 0 and 59.

This comparator will work with any textual file (xml, csv, edifact, x12, ...), but not with binary files (pdf, ...).  It will work line by line, requiring that the 2 compared files are the same in the sense that they have the same number of lines, and every corresponding line match, taking into consideration the comparison rules defined for this line.

The need for this comparator is very common. For example, when you test a transformation that converts an invoice from one format to some other, it is very likely that you want 99% of the output file to be the same at every run of the test case (for example every invoice line, with the right articles, quantities, prices, taxes, ... ). But it is also very common that the generated file must contain a few other fields, like the current date, or some uniquely generated id. These fields prevent the usage of the binary comparison, as the test case would always fail, complaining that the values in these few fields are not as expected. But not checking at all the message output would lead to a test case that would be really weak, and would not detect any of the mistakes that you could do in your mapping (missing an invoice line, forgetting some fields, making a wrong price or tax calculation, ...).

 

To configure the textual comparison, just select the "Textual comparison", and provide an example of your expected content. An additional encoding parameter allows you to tell the system which encoding should be used to interpret the contents as text. It applies both to the expectedMessageOut that you provide, and to the actual messageOut that will be the result of the test.

Once this is done, you can click on the "Define advanced comparison rules" button to configure the advanced rules. This will open an editor where you will see your expected message out content, and will be able to configure the exception rules.

The left pane of this editor will just be your expected content. The right panel will contain the list of all the comparison rules that you have defined (on top), and a small pane that allows you to add/edit rules.

To add a new rule, the easiest way is just to select in the editor the characters for which you want to define the exception. The line and positions fields in the add/edit form will be automatically filled to match your selection. Once you have done that, you can just click on "Add new rule" and you have finished to define your exception. The selected characters will be ignored in the comparison.

Optionally, when you define the rule, you can also switch the Behavior field from Ignore to Regexp. This will allow you to enter a regular expression that must be satisfied by the actual content at this place.

You can edit a rule by just clicking on it in the list of rules (pane at top right), make the needed changes, then click on "Edit rule".

For example, in the above screenshot, the test case expects that the message out is composed of 8 lines, and that all lines are exactly equal to what is shown, except for the 2 fields that represent the date and time at line 7. The date field will be considered as ok for any sequence of 10 characters, while the hour field is also expected to match the provided regular expression, saying that it must be 2 digits, a colon and 2 digits again.

When you have finished defining all your rules, you can click on Exit editor. Don't forget to Save the test case.

 

Expected metadata

This success condition allows you to check that some user metadata have correctly been calculated by your channel.

This is very useful where you processing flow involves multiple consecutive channels. In that case, it is very common that a prior channel calculates a few metadata, that will later be consumed by a subsequent channel. With this condition, you can test that the prior channel correctly calculates what is expected for the next steps.