The ITP test cases are defined using YAML files. Each file is composed of several fields that are interpreted by the platform to carry out tests and validations of the different use cases paths. This page describes the basic model of a YAML file for the test platform.
Proposing New Test Cases
Any party interested in using the Interoperability Test Platform can propose new test cases using the template presented here. For this, it is important to follow the creation guide starting from a use case, to understand its application context, then determine which paths should/need to be tested. Then, it is possible to use the template shown below to create the test cases for each path. The creation of new test cases is based on the following roadmap:
- Elaboration and understanding of the scenario you want to test;
- Creation of a use case that can be implemented by ITP;
- Description of the use case following the model available here;
- Definition of the paths that should be tested for the use case (happy and unhappy flows);
- Preparation of each test case following the model below.
Test Case Data
The Test Case Data is the first part of the YAML file. It contains seven fields used as a header to specify particular characteristics related to the test case and the use case it belongs to. Below you can see a table with the fields used in the header and an example of the test case data in a YAML file.
|The name of the Test Case that will be shown to users. Names do not need to be unique, so it is possible to have multiple Test Cases with the same name.||Authorized Transaction by Payer FSP|
|The name of the Use Case that the Use Case is related to. This should be identical for all Test Cases sharing a Use Case.|
|Defines the type of the Test Case, i.e. "Happy flow" (|
|A description of the Test Case. It is useful to include some business background of what we are trying to achieve in this case.||The Service Provider wants to test if he is capable of receiving a transaction from a different wallet...|
|An additional area describing specific values that should be used to execute a Test Case. This may include directions for using test case triggers.|
|A list of components involved in the that the Test Case. Some Test Cases involve MMOs only (P2P transfer) or contain some specific errors that can only be received by SUT and not handled by it.|
|Contains details of the steps involved in the test case.|
Example of test case data in a YAML file
Test Step Data
The second part of the test case file is called Test Step Data. Each step represents an HTTP request made as part of the test, and is defined by a series of common values, in addition to step-specific parameters such as assertions, overrides and request and response examples.
These common values are present in every step of the test case.
|The request method that will be used to match a message.|
|The a regular expression will be used to match a message using the request path.|
|The path that will be shown on Flow Diagrams and on Test Run steps that were not executed.|
|The sender of the request. Should be a Component name from the database. Will be used to match a message|
|The recipient of the request. Should be a Component name from the database. Will be used to match a message|
|The trigger value(s) that should be used to match a message.|
|The API spec to perform schema validation. Should be a Specification name from the database.|
Example of Global Values in a YAML file
Assertions can be used to validate that certain business conditions hold, in a
more powerful way than is possible using API schema validation. Assertions can
be performed for any value in the header or body of the request or response. In
a response, the
status field may also be used for assertions.
|A list of assertions that will be performed for the request.|
|A list of assertions that will be performed for the HTTP response.|
Each request/response may have a number of assertions, and each assertion is
defined by a
name and a list of Laravel validation
rules. The key for each
rule is a path to a field using 'dot' syntax within the request/response object.
For more information on the syntax of these rules, visit the
Laravel documentation site.
Each validation rule should contain the
required rule at least, otherwise the
assertion may pass even if the value is wrong or empty.
Overrides are used in situations where it is necessary to force a value provided by a simulator to have a different value for the purposes of directing the test flow.
|The list of overrides that will be performed for the request.|
|The list of overrides that will be performed for the response.|
|The name of the override that will be shown on the Test Step page.|
|The list of overrides that should be performed per request/response. Overriding will override the existing values in the message or create a new one if it does not already exist.|
Override values can either be provided using dot-notation to override a single
value, or a whole object can be overridden by providing an object as in the
Force 400 error example below, where an object has been passed to the
Request and Response Examples
Each test step is also defined by an example request and response. This provides guidance for test platform users, to identify what data he needs to send or can expect to receive during the test execution. Importantly, the example request defined in the first test step is also used by the test platform to trigger the start of a test run when the "Execute Test" button is clicked within the test platform.
|uri||An example path or URI for this request/response.|
|headers||A list of expected headers.|
|body||An example payload for the request/response.|
|status||Example response status.|