Test harness testing guide

Introduction

The consent and authorisation stub can be used by pension providers during system testing. It implements the consent and authorisation API, which the system-under-test will interact with.

It also provides ways to check the behaviour of that system so testers can verify that each test scenario passes. There are two main mechanisms to assert the correct behaviour:

1. The call log. This is a log of all the HTTP calls (and responses) made to the consent and authorisation stub. By inspecting the log, a tester can verify that the expected calls were made with the correct parameters and correct responses.
2. The consent and authorisation stub internal database. As calls are made to the consent and authorisation stub, data is stored and updated in its internal database. This can be queried to verify that the correct calls were made by the system-under-test.

Version

This is version 2.2 of the test harness testing guide.

Downloads

Download error-scenarios-postman-collection.zip

This zip folder contains:

• 8. MaPS System Testing - Error scenarios.postman_collection (1).json

Download crypto-pack-for-system-testing.zip

This zip folder contains:

• certificate.json
• certificateChain.json
• certPrivateKey.json
• certPublicKey.json
• jwtPrivateKey.json
• jwtPublicKey.json
• kid.json

Download supplementary-crypto-material-for-system-testing.zip

This zip folder contains:

• postmanCertificate_expired.key.pem
• postmanCertificate_expired.pem
• postmanCertificate_invalid.key.pem
• postmanCertificate_invalid.pem
• postmanCertificate_valid.key.pem
• postmanCertificate_valid.pem
• README.md
• SUT_trusted_CA.pem

Prerequisite: starting the consent and authorisation stub

For instructions on setting up and running the consent and authorisation stub, refer to the accompanying test harness administrator guide.

This chapter assumes that the consent and authorisation stub is up-and-running, and that the call log is configured to be accessible. We assume the system-under-test is configured to use it instead of the real consent and authorisation, ready for the test scenarios to be tested.

Running the test scenarios

It is assumed that the test scenarios will be run one at a time. This allows the checks to be made more easily against the consent and authorisation stub, as the calls made and resources created/edited during that specific test scenario can be easily identified.

Each test scenario is defined in the test pack, in the accompanying test scenarios.

Columns “Request log output” and “Response log output” give details of the expected interaction with the consent and authorisation stub, and thus what to assert.

To collect evidence that each scenario has been run successfully, it is recommended to copy from the consent and authorisation stub call log the requests and responses sent during that scenario. These can be added to the evidence document submitted to MaPS to say that system testing has been completed successfully.

View request parameters

For some test scenarios, the ‘view’ requests sent with Postman require parameters to be set that match resources created during a previous ‘find’. The tester must look up these values, and configure the Postman request accordingly.

Asset GUID (resource ID)

For some ‘view’ test scenarios, the Asset GUID needs to be supplied in the Postman call. If you are using the dummy ISP created for testing the test harness, this must match the resource created from a corresponding previous find request. If you are sending the Postman call to a genuine Resource Server, use the Asset GUID generated by the Resource Server when the pension match was registered.

This is shown in the Postman request’s URL path as {{asset_guid}}.

One way to retrieve this is to use the consent and authorisation stub call log. When handling the ‘find’ request, there will have been a call to the /rreguri endpoint. The response to this will show the resource ID. For example, see the example below (with the resource_id highlighted):

Setting the request party access token (RPT)

For some ‘view’ test scenarios (for example, scenario 29 and 30), the Postman call needs to be configured with the RPT. It must match the resource created from a previous find request.

In production usage, the system-under-test would not need to worry about retrieving the RPT: the system will receive find and view requests (it is the responsibility of other systems to ensure a valid RPT is passed).

However, the tester must send valid find and view requests to exercise the system-under-test. This means the tester has the extra responsibility of ensuring the RPT in the view request matches the RPT generated by the previous find request.

Before sending the ‘view’ request, the tester must ensure that an appropriate “find” request has been processed.

The simplest way for the tester to retrieve the RPT is by querying the database directly. After running the find scenario, the tester can execute the following database query (substituting in the resource_id that was returned in the response to the /rreguri request):

To use the RPT in the Postman view request, set the authorization Bearer Token of that Postman request to the RPT for the resource.

The Auth Type is set to “Bearer Token”, and the “Token” value is set the RPT (in the screenshot below, this is the value beginning “eyJhY…”).

Optional: additional error handling scenarios

The error handling scenarios are chosen to give good coverage without asking testers to run through every permutation.

The consent and authorisation stub supports simulating other error scenarios. For example, as well as simulating a 500 error, it can simulate a 502, 503 and 504 error.

The error behaviour in the consent and authorisation stub is triggered by using pre-defined UAT (user account tokens) and RPT (request party access token). When that specific UAT or RPT is received, it causes the consent and authorisation stub to return the pre-defined error code.

Testers can create variants of the supplied test scenarios by adjusting the UAT and/or RPT in that scenario.

Variants of ‘find’ error scenarios

To find the alternative UATs for ‘find’ scenarios, query the consent and authorisation stub Internal database. Query the CAS_USER table to get the UAT. The friendly name indicates which error this will produce, such as “Assertion User for /rreguri POST 502 bad gateway scenario”.

To configure this within the Postman ‘find’ request, edit the body of the request to change the ‘user_account_token’ value, to use the desired UAT.

Variants of ‘view’ error scenarios for/introspect failing

To find the alternative RPT for ‘view’ error scenarios where the /introspect endpoint fails (for example, error scenario 21), query the consent and authorisation stub Internal database. Query the CAS_REGISTERED_RESOURCE table to get the RPT. The friendly name indicates which error this will produce, such as “assertion user for /introspect 502 bad gateway scenario”.