Validating message fields
For fields that are of the type Message, the contents of the Validate tab changes. The options enables you to validate the structure of a message (or its child elements) rather than its individual attributes.
- Validating element children
- Validating message children
- Validating by using a tag
- Validating by using a message from file
- Assert by using function
- Validate against contract
Validating element children
Select the additional options, as follows:| Option | Description |
|---|---|
| Accept fields in any order | Test Integrations and APIs ignores the order in which message fields are received. This option can be useful since messages sent on certain transports can undergo field-reordering. |
| Fuzzy match duplicates | When the Fuzzy match duplicates option is enabled, Test Integrations and APIs finds the nodes that match and selects the node which causes the least errors. However, this might not be the best match with the best results. You can enable this option when nodes with the same name exist. When this option is disabled, nodes with the same name are matched based on their position only. |
| Ignore missing fields in received message | When enabled, any fields present in the expected message structure but absent in the message that is received do not cause invalidation. |
| Ignore additional fields in received message | When enabled, any fields present in the received message but absent in the expected message structure do not cause invalidation. |
Validating message children
Configure the General settings as follows:| Option | Description |
|---|---|
| Accept fields in any order | Test Integrations and APIs ignores the order in which message fields are received. This option can be useful since messages sent on certain transports can undergo field-reordering. |
| Fuzzy match duplicates | When the Fuzzy match duplicates option is enabled, Test Integrations and APIs finds the nodes that match and selects the node which causes the least errors. However, this might not be the best match with the best results. You can enable this option when nodes with the same name exist. When this option is disabled, nodes with the same name are matched based on their position only. |
| Ignore missing fields in received message | When enabled, any fields present in the expected message structure but absent in the message that is received do not cause invalidation. |
| Ignore additional fields in received message | When enabled, any fields present in the received message but absent in the expected message structure do not cause invalidation. |
Ignoring the descendent nodes and its following siblings
- Namespace URI (optional): Enter the namespace URI that you have created for the fields to be ignored.
- Name: Enter the name of the field.
Validating by using a tag
To compare a received value against a message or submessage that was previously tagged, select the Validate Using Tag option.
Select the existing tag against which the comparison is to occur from the Validate against tag menu. If there are any fields that are to be ignored in the comparison, you can enter an XPath representation of them under Exceptions.
Validating by using a message from file
It is possible to validate a message against a previously saved version of the message.
In the following example, we created a two-step test where the first step publishes data from a file and the second step subscribes to the published data and compares the data to messages that were previously saved. The publish step provides us with the tagged data that allows us to specify the name of the file we want to compare the data with in the subscribe step.
To enable validation against a saved message file, edit the message in the subscribe step and double-click the top (Message) node of the message. Next, select the Validate Using Message from File action type.
Click Select to choose a message resource file. Select the wanted message from the Select Resource dialog and click OK when finished.
The message location is displayed as a path in the field editor (for example, /Test Data/Output Data/myMessage.)
It is possible to make the file name dynamic (that is, generated from data that are received in the incoming messages) by substituting a tag for a portion of the message path. In the example that is shown, only the message folder name is being substituted.
You are now ready to run the test. For each message to which the test subscribes, a comparison is made to the message in the file that matches the resource file name that is constructed by the published tag.
If you are not interested in comparing some of the fields (for example, date fields, which are likely to change), validation exceptions can be added. Paths to fields that are not to be included in the validation must be entered in the Exceptions field.
In the example that is shown, validation is not carried out against the ReviewDate attribute or against any of the rating elements for each of the songs.
Assert by using function
You can access the received value of the field within the message by using the FIELD/VALUE tag.
Validate against contract
It is possible to validate a message against a contract. To be able to validate against a contract, you must have defined a schema for the message and selected a root in the schema. The contract is adhered to when the schema in the incoming message matches the schema defined for received messages. If the validation fails the contract is rendered as broken or invalid.
When you synchronize API resources and a schema exists for the expected API responses, Test Integrations and APIs can create Contract tests under an operation when you select the Contract Tests as the option to create tests.