| Expand | ||||
|---|---|---|---|---|
| ||||
|
1. Purpose
The purpose of the tool is to provide implementers with a reliable and efficient test tool for ensuring conformance to the Ozone Connect implementation within the
...
API Hub. This tool aims to simplify the testing process, ensure adherence to standards, and enhance the overall quality and interoperability of implementations.
2. Scope
This manual covers the essential aspects of
...
the Testing Tool, including its installation, usage, and testing capabilities. It provides detailed instructions and guidelines to help users effectively utilise the tool within their development and testing environments. The scope includes:
Installation and setup | Provides instructions for installing and setting up |
...
the Testing Tool using Docker, including prerequisites and initial configuration. This tool has been successfully tested on Ubuntu Linux and on MacOS. | |
Usage instructions | Details the commands and options available in the |
...
Testing Tool CLI tool, with examples for effective usage. | |
Testing | Explains the testing procedures and conformance checks, including how to run tests and interpret the results |
...
3. Audience
The primary audience for this manual includes developers, QA engineers, and technical implementers who are involved in the integration and testing of the Ozone Connect implementation for the
...
API Hub.
QA engineers | Professionals responsible for ensuring the quality and reliability of the Ozone Connect implementation by conducting thorough testing and identifying defects. |
Integration Specialists | Experts focused on integrating and aligning the Ozone Connect implementation with the |
...
API Hub to ensure seamless interoperability and conformance. |
This manual assumes that the audience has a basic understanding of CLI tools, Docker, CBUAE Open Finance
...
Standards and Ozone Connect specifications.
4. Overview
...
The Testing Tool is a command-line interface (CLI) based testing tool designed to assist implementers in verifying their conformance to the Ozone Connect implementation. Developed specifically for the
...
API Hub,
...
the Testing Tool provides a comprehensive suite of tests that validate various aspects of the implementation against the predefined standard. The tool runs within a Docker container, ensuring a consistent and isolated testing environment. By using the
...
Testing Tool, implementers can efficiently identify and rectify issues, ensuring that their implementations meet the required conformance criteria.
5. Setup Requirements
Before You Start:
Familiarise yourself with the Ozone Connect
...
Ensure you have https://www.docker.com/ installed locally on your machine to run Docker containers.
6. Usage
The instructions below are based on using
...
the Testing Tool to test against the Ozone Connect v2024.34.00
...
Step 1
...
Below is the command which runs the Testing Tool Docker container with the specified configuration and logging options for running the tests against the mock Ozone Connect Server hosted in the cloud:
| Code Block |
|---|
#Sample command without any client configuration being provided docker run --user root --rm -it \ -v "$(pwd)/logs:/usr/o3/tr-ozone-connect/logs" \ public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:cbuae |
...
The container includes a configuration file with the necessary test data, base URL, and ozone transport certificate locations.
Use the provided command to start the container and run the testing tool.
The command is divided into two parts: the Docker run command with required parameters and the yarn tr-ozone-connect command to run the test framework.
...
\
yarn tr-ozone-connect \
--formatter terse \
--loglevel-runner debug \
--config /usr/o3/tr-ozone-connect/config/test-input.yaml \
--out /usr/o3/tr-ozone-connect/logs/<custom_log_file_name> |
In order to run the tests against the LFI’s implementation of Ozone Connect the next command should be executed:
| Code Block |
|---|
#Sample command WITH the client configuration being provided docker run --user root --rm -it \ -v "$(pwd)/config:/usr/o3/tr-ozone-connect/config" \ |
...
-v "$(pwd)/ |
...
logs:/usr/o3/tr-ozone-connect/logs" \ |
...
public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:cbuae \ |
...
yarn tr-ozone-connect \ |
...
--formatter terse \ |
...
--loglevel-runner debug \ |
...
--config /usr/o3/tr-ozone-connect/config/test-input.yaml \ |
...
--out /usr/o3/tr-ozone-connect/logs |
...
Step 2
...
The final section of the sample output, after all tests have been run and logs have been printed, will appear as follows.
...
Step 3 (optional)
...
Review the Ozone Connect Testing Tool output log file containing the test case results. The log file's name is specified in the last part of the command in step 1 above. You can change this name each time you run the command. If not changed, successive runs will overwrite the same file.
...
/<custom_log_file_name> |
In order to run the above command against LFI’s implementation of Ozone Connect, the LFI needs to:
Create an input test configuration file and put it in a
/configfolder.Acquire or generate the SSL certificates to connect to the Ozone Connect server.
Put the certificates in a
/config/certsfolder.Execute the command from the same
/configfolder to run the tests.
For details of what options for running the tool are available and examples, please review section 6 below.
6.1 Options
The command provided above can be broken down into three main parts:
Running the Docker Container: The first part runs the Testing Tool Docker container, mounting the necessary directories and setting up the environment:
Option | Description |
|---|---|
| If the LFI configuration is not provided, the tool will attempt to connect to a the Ozone Connect mock server deployed by Ozone in the cloud. For detailed information on the configuration file format, please refer to the configuration file section: https://openfinanceuae.atlassian.net/wiki/spaces/APIHubDocsv3/pages/151126094/Testing+Tool+User+Guide#6.2-Configuration-File SSL certificates are necessary for secure mTLS connection between the Testing Tool and LFI’s implementation of Ozone Connect. The method to generate these certificates is documented in the Certificates Generation section: https://openfinanceuae.atlassian.net/wiki/spaces/APIHubDocsv3/pages/151126094/Testing+Tool+User+Guide#6.3-Test-Certificates After generating the certificates, copy them into a folder named |
| This option is mandatory and needs to be passed to check the logs after the program has run. The logs will be available in this folder after the tests are run. |
Acquiring the latest docker image:
Option | Description |
|---|---|
| This is the location of the publicly available Test Tool Docker image. |
Executing the Ozone Testing Tool: This 3rd part executes the Ozone Testing Tool within the container with a set of specified options:
Code Block yarn tr-ozone-connect \ --formatter terse \ --loglevel-runner debug \ --config /usr/o3/tr-ozone-connect/config/test-input.yaml \ --out /usr/o3/tr-ozone-connect/logs/logs_5Aug.json
7. Test Cases
Following test scenarios have been implemented to check the below:
Response code validations.
Response schema validations.
Response data validations.
The tests below are a subset of a broader range of tests. New tests will be introduced gradually as the Ozone Connect Testing Tool is updated and new versions of CBUAE Open Finance Standards are released.
7.1 Bank Data
GET /accounts
...
Scenario
...
Response
...
Expected outcome
...
Valid accountIds are included as a query parameter, each with distinct SubTypes like CurrentAccount, Savings, and CreditCard for a retail user in Active status
...
200
...
Returns a 200 if all headers are valid and returns a record for each specified accountId including CurrentAccount, Savings, and CreditCard for a retail user with status 'Active' and validate correct accountType and accountSubType fields are populated for each accountId
...
No accounts found
...
200 with an empty array
...
Returns a 200 if all headers are valid no account information is found for the specified accountId
...
Missing accountIds query parameter
...
400
...
Fails with 400 if accountIds query param is missing
Header validations:
Requirement
...
Scenario
...
Response
Expected outcome
...
AIS:
Get accounts
...
Missing o3-psu-identifier header
...
400
...
Fails with 400 if o3-psu-identifier is not specified
...
AIS:
Get accounts
...
Invalid o3-psu-identifier header - not a base 64 encoded value
...
400
...
Fails with 400 if o3-psu-identifier header is invalid - not a base 64 encoded value
...
AIS:
Get accounts
...
Invalid o3-psu-identifier header - value is base 64 encoded, but the decoded value is not valid JSON.
...
400
...
Fails with 400 if o3-psu-identifier header is invalid - not a valid json
...
AIS:
Get accounts
...
Invalid o3-psu-identifier header - the decoded value is valid JSON, but it lacks the userId parameter.
...
400
...
Fails with 400 if o3-psu-identifier header is invalid - the decoded value is valid JSON, but it lacks the userId parameter
...
AIS:
Get accounts
...
Missing o3-ozone-interaction-id header
...
400
...
Fails with 400 if o3-ozone-interaction-id header is not specified
...
AIS:
Get accounts
...
Missing o3-api-operation header
...
400
...
Fails with 400 if o3-api-operation header is not specified
...
AIS:
Get accounts
...
Missing o3-aspsp-id header (o3-provider-id)
...
400
...
Fails with 400 if o3-aspsp-id header param is not specified
...
AIS:
Get accounts
...
Invalid o3-aspsp-id header (o3-provider-id)
...
400
...
Fails with 400 if o3-provider-id header is invalid
GET /accounts/{accountId}/transactions
...
Scenario
...
Response
...
Expected outcome
...
Valid accountId provided in the path parameter which has a list of transactions
...
200
...
Returns a 200 if all headers are valid and Returns transactions of specified accountId
7.2 Bank Service
GET payments/{paymentId}
Scenario | Response | Expected outcome |
|---|---|---|
Inquire a 'Pending' Single Immediate domestic payment Note: When conducting the tests as described above, the main goal is to verify that all payments in different statuses can be accessed with the accurate schema and data structure | 200 with payment details in the response | Returns a 200 with correct schema and in the response the payment status is 'Pending', and the paymentId matches the paymentId in the path parameter |
7.3 Insurance
<TODO>
7.4 Health Check
...
Option | Description | Possible Values |
|---|---|---|
-h, --help | Show help (boolean) | |
-c, --config | Input test configuration files in .yaml or .json format | config.yaml, config.json, ./config/test-input.yaml |
-f, --folder | Preconfigured path to the folders with the test files | src/tests, tests, ./src/tests |
-r, --regex | Regex patterns to match test cases. Runs a test that matches any of the patterns | pattern1:regex1#pattern2:regex2 |
-o, --out | Output file name | results.json, output.yaml, ./test_output.txt |
-e, --formatter | Use a standard formatter for the output | full, terse, medium, errors |
-t, --output-format | File output format when not using a template | json, yaml |
-v, --loglevel-runner | Log level for the test runner (Format : string, optional) | debug, info, silent, debug |
-l, --loglevel-suite | Log level for the test suite (Format : string, optional) | debug, info, conditional |
--version | Show version number (boolean) |
6.2 Configuration File
This section provides a detailed explanation of the configuration file fields used in the Testing Tool for Open Banking APIs.
A sample configuration file (test-input.yaml) is as follows :
| Code Block |
|---|
baseUrl: https://mock.rt-cbuae.rt.dev.ozoneapi.co.uk
psuIdentifier:
userId: '10000100000000000000002'
aisBasePath: openbanking/v1/ais
pisBasePath: openbanking/v1/pis
accounts:
validAccountIds: ['100004000000000000000001']
payments:
paymentIds: ['abcdef1234567890']
headers:
o3-ozone-interaction-id: 'e2ff21ca-dd11-4c05-98ef-403dcc8e588d'
o3-api-operation: 'GET'
o3-aspsp-id: 'RTCBUAE'
o3-api-uri: 'open-banking/account-information/v1/accounts'
o3-caller-org-id: '000015000000000000000001'
o3-caller-client-id: '65e64982-f080-4785-a887-816f5274ea7e'
o3-caller-software-statement-id: '000016000000000000000004'
o3-consent-id: 'aac-6359d9-ab01458-c45a358cbf3230733'
o3-psu-identifier: 'eyJ1c2VySWQiOiIxMDAwMDEwMDAwMDAwMDAwMDAwMDAwMDIifQ=='
providerId: 'RTCBUAE'
supported:
accounts:
multi: true
single: true
certs:
transport:
ca: '/usr/o3/tr-ozone-connect/config/ozone2021-ca.pem'
certFileName: '/usr/o3/tr-ozone-connect/config/ozone-issued-transport-HQuZPIt3ipkh33Uxytox1E.pem'
keyFileName: '/usr/o3/tr-ozone-connect/config/ozone-issued-transport-HQuZPIt3ipkh33Uxytox1E.key'
|
Configuration | Description |
|---|---|
baseUrl |
|
psuIdentifier
|
|
aisBasePath |
|
pisBasePath |
|
accounts
|
|
payments
|
|
headers
|
|
headers
|
|
headers
|
|
headers
|
|
headers
|
|
headers
|
|
headers
|
|
headers
|
|
headers
|
|
headers
|
|
supported
|
|
supported
|
|
certs
|
|
certs
|
|
certs
|
|
6.3 Test Certificates
The certificates in the certs folder are critical for securing communications between the LFI and the OFP using mTLS.
Below you can find a brief explanation of how you can generate test certificates in order to run the testing tool against your implementation.
Please keep in mind that you can also use certificates provided by OFTF. In this case please skip certificate generation step.
Steps to Generate Test Certificates:
Create a Certificate Authority (CA)
A CA is responsible for signing certificates. If you do not have an existing CA, you can create one.
Generate the private key for your CA:
openssl genpkey -algorithm RSA -out ozone2021-ca.key -aes256Create a self-signed root certificate:
openssl req -x509 -new -nodes -key ozone2021-ca.key -sha256 -days 365 -out ozone2021-ca.pem
Generate a Private Key for the Server
Generate the private key for your server:
openssl genpkey -algorithm RSA -out ozone-issued-transport.key -aes256
Create a Certificate Signing Request (CSR)
Generate a CSR using the server's private key:
openssl req -new -key ozone-issued-transport.key -out ozone-issued-transport.csr
Sign the CSR with Your CA
Use your CA to sign the CSR, creating the server certificate:
openssl x509 -req -in ozone-issued-transport.csr -CA ozone2021-ca.pem -CAkey ozone2021-ca.key -CAcreateserial -out ozone-issued-transport.pem -days 365 -sha256
Verify the Certificate
Ensure the certificate is correctly generated and can be verified against the CA:
openssl verify -CAfile ozone2021-ca.pem ozone-issued-transport.pem
Summary of Files
CA Certificate (ozone2021-ca.pem)
The root certificate used to sign other certificates.
Server Private Key (ozone-issued-transport.key)
The private key for the server, kept secure and not shared.
Server Certificate (ozone-issued-transport.pem)
The public certificate signed by the CA, used for secure communications.
7. Running Testing Tool
Follow the instructions below to run the Testing Tool:
Step 1 | Create an input test configuration file and set up it in | Please follow the Configuration File section in order to generate the required file: https://openfinanceuae.atlassian.net/wiki/spaces/APIHubDocsv3/pages/151126094/Testing+Tool+User+Guide#6.2-Configuration-File | ||
Step 2 | Acquire/Generate the SSL certificates and put them in a | Please follow the Test Certificates section in case you need to generate test certificates: https://openfinanceuae.atlassian.net/wiki/spaces/APIHubDocsv3/pages/151126094/Testing+Tool+User+Guide#6.3-Test-Certificates Otherwise please use OFTF Certificates. | ||
Step 3 | Execute the testing tool command. |
| ||
Step 4 | The final section of the sample output, after all tests have been run and logs have been printed, will appear as follows. |
| ||
Step 5 (optional) | Review the Testing Tool output log file containing the test case results. The log file's name is specified in the last part of the command in step 1 above. You can change this name each time you run the command. If not changed, successive runs will overwrite the same file. | Use any text editor to view the file : |
8. Test Cases
The list of supported test cases is available in the following document: Ozone Connect Test Cases