Skip to main content

Test Case Matching

A single testing session will contain tests for multiple use cases, each of which may contain multiple test cases. This is useful for rapid testing under a variety of conditions, but means the platform must automatically identify which test case is being executed when a request arrives at the platform. For example, a session may contain two flows which differ only in whether a quote is accepted or rejected by a remote DFSP. In this case, the test platform must identify which flow is being executed, in order validate the requests and instruct the remote DFSP simulator to accept or reject the quote.

For every test case within the session, the first unmatched step is selected to compare against the incoming request. For test cases which have not yet been started, the very first step of the test case is selected. First, the request's basic characteristics are considered to determine which of the test steps may match. These characteristics are:

  • The request method (GET, POST, PUT, etc)
  • The request path (/transactions, /batchtransactions/{batchId})
  • The request source and destination components (Mobile Money API Provider, Service Provider)

It is frequently the case that multiple test steps will still be possible matches at this stage, since many test cases test fairly similar flows. In the example given above for example, these characteristics would be identical for both the accepted and rejected cases, since both follow the same basic flow of requests. To disambiguate between them, a further check is required, known as test triggers.

Test Triggers​

A test trigger takes the form of a JSON object which must be present within the body of a request for it to match against the test step. For example, a test step might be defined with a trigger of:

{ "amount": 20.03 }

If a request arrives at the platform with a body containing the following, the test case would be considered a match:

{
  "payerid": { "type": "MSISDN", "id": "123456789" },
  "amount": 20.03,
  "currency": "EUR"
}

However, a request with this body would not be considered a match:

{
  "payerid": { "type": "MSISDN", "id": "123456789" },
  "amount": 20.04,
  "currency": "EUR"
}

In this way, multiple test cases can be defined unambiguously while sharing almost identical flows. Returning to the example above, the accepted case may be defined with a trigger of {"amount": 20.03} while the rejected case is defined with a trigger of {"amount": 20.04}. The two test cases can then be executed in any order (or even simultaneously) with no conflict between them.

If a test case has a trigger, it will be defined in the "Precondition" section of the test case page. An example can be found below:

trigger_example

Identical Requests​

In the case that neither the request body nor the request path contain any data which may be used as a trigger, it is not currently possible to disambiguate any further. As a result, it is not possible to execute multiple test cases simultaneously, since the platform will not be able to determine which test case is under execution.

To allow testing such similar scenarios, the compliance platform defines an option FORCE_SEQUENTIAL_TESTS which is false by default. When the option is enabled, test executions are expected to be sequential - so a single session should never have two parallel test runs. By making this assumption, it becomes possible to unambiguously select one of several identical test cases by simply clicking the "Run Test Case" button for the desired test case. This will initiate the test case execution, and any requests received by the platform will be automatically matched to the current test case until the test run is complete.