ITP Test Cases
Where an ITP Use Case represents the different goals that actors within the system might have, a test case represents a specific path taken to achieve a goal. Test cases are separated into "happy" and "unhappy" so that they cover all the possibilities for a use case. Tests typically include several alternative paths that evaluate the exceptions and errors in the use case. It is also possible that there are several happy paths, addressing different business rules that result in different expected outcomes.
All test cases currently available on the Interoperability Test Platform are listed below. As new test cases are created, the documentation, and therefore the list, will be updated. The list of test cases is split according to use cases and contains the following attributes:
Test Case Code: Code that identifies the test case in relation to the others. The code consists of two parts: an acronym that is directly related to the use case, and a code that differentiates tests for the test group to which it belongs (e.g. P2P0057 is the test case 0057 for the use case P2P).
Test Case Scenario: This field is made up of properties that define the scenario in which the test case is being executed. These are the specific parameters that define a scenario, such as: fees and commissions involved, use of an account lookup system, currencies supported by the provider, etc.
Status: Expected results after running the test case. The result indicates whether the evaluated path is a "happy" flow or "unhappy" flow.
Results: The results field indicates the expected behaviour for test cases under validation. Particularly when dealing with rejected transactions, the value of this attribute gives a better understanding of the reason for not carrying out the transaction.
Error Number: Indicates the number of the current error for the test case. This will generally be a 3-digit (for HTTP errors) or 4-digit (for Mojaloop errors) error code, which can be understood with reference to the documentation for the APIs under test. For example, the Error Number 5103 corresponds to the Mojaloop error indicating that the Payee doesn’t want to proceed with the financial transaction after receiving a quote.
List of Test Cases
Merchant-Initiated Merchant Payment
| Test Case | Test Scenario | Results | Status | Error |
|---|---|---|---|---|
| MC0100 | Authorized Transaction | Approved | Pass | - |
| MC0200 | Authorized Transaction w/ Account Lookup | Approved | Pass | - |
| MC0300 | Authorized Transaction w/ Authorisation Codes | Approved | Pass | - |
| MC0400 | Declined Transacation | Declined | Fail | 400 |
| MC0500 | Declined Transacation | Declined | Fail | 401 |
| MC0600 | Declined Transacation | Declined | Fail | 404 |
| MC0700 | Declined Transacation | Declined | Fail | 500 |
| MC0800 | Declined Transacation | Declined | Fail | 503 |
| MC5001 | Rejected Quote | Quote Rejected by Payee | Fail | 5103 |
| MC5002 | Rejected Transaction | Transaction Request Rejected Late by Payer | Fail | 4101 |
| MC5003 | Rejected Transaction Request | Transaction Request Rejected by Payer | Fail | 4101 |
Customer-Initiated Merchant Payment
Peer to Peer
| Test Case | Test Scenario | Results | Status | Error |
|---|---|---|---|---|
| P2P0100 |
| Approved | Pass | - |
| P2P0200 |
| Approved | Pass | - |
| P2P0300 |
| Approved | Pass | - |
| P2P0400 |
| Approved | Pass | - |
| P2P0500 |
| Approved | Pass | - |
| P2P0600 |
| Approved | Pass | - |
| P2P0700 |
| Approved | Pass | - |
| P2P0800 |
| Approved | Pass | - |
| P2P5001 |
| Quote Rejected by Payee | Fail | 5103 |
| P2P5002 |
| Quote Rejected by Payee | Fail | 5103 |
| P2P5003 |
| Quote Rejected by Payee | Fail | 5103 |
| P2P5004 |
| Quote Rejected by Payee | Fail | 5103 |