Integration test pack

Introduction

This document covers the mandatory integration testing phase, to be performed by every organisation connecting in the Money and Pensions Service (MaPS) pre-production environment.

Integration testing is the final testing phase before any such providers are promoted to the MaPS live environment.

Connecting organisations must demonstrate to PDP that they have successfully completed their own internal system testing and submitted their results through the connection portal. They will then be given permission by PDP to begin integration testing within the MaPS pre-production environment. The MaPS system testing test pack contains full details of this process.

Most of the tasks in the document are done by the PDP integration test team, but it should be useful for connecting organisations to understand the process.

Downloads

Download integration test pack materials

This zip folder contains:

• Integration test data v1.2.xlsx
• Integration test cases v1.1.docx
• Integration testing issues tracker v1.0.xlsx

Context

Integration testing uses a limited set of requests to test functional and non-functional aspects of each connecting organisation’s solution to confirm it is compliant with PDP standards and that it successfully integrates with the PDP central digital architecture (CDA).

This testing phase is not intended to be a comprehensive test of all required functionality. It is designed to assure PDP that the connection organisation is correctly onboarded and that user journeys operate as expected. It will also confirm that view data payloads are compliant with the PDP view data schema and that the payload is appropriate for the match type. However, it will not assess the correctness of data attributes in any payload.

The connecting organisation should have already tested their solution to assure its functional and non-functional completeness and its compliance with all PDP standards.

We maintain a list of issues experienced during connection proving. PDP recommends you check these to see what issues were encountered and the advice given to resolve the issue. These can be found in the download zip file.

Reference documents

Connecting organisations scheduled to onboard in 2024 will be tested against a CDA that conforms with:

• PDP data standards (including supporting json schemas)
• PDP technical standards (including supporting json schemas and yamls)
• PDP code of connection

You can find these on the PDP standards page.

Connecting organisations must also meet the PDP code of connection, but integration testing will not confirm adherence to this standard.

Some of these tests will check that the solution meets fundamental code of connection requirements. For example:

• tests must acknowledge receipt of a find request in less than 2 seconds
• tests will wait up to 70 seconds for the match to be registered before attempting to obtain its pension identifier (PeI) requests, and responses will be signed or encrypted as per the requirements of PDP technical standards and the code of connection

If any of these requirements are not met, the test will be recorded as a ‘fail’.

Setup environment and testing responsibilities

The integration testing will start by configuring the MaPS pre-production environment for the provider or ISP under test.

Test execution is comprised of 3 parts; connection proving, stage 1 and stage 2.

The testing responsibilities of each stage are specified below:

• PDP testers must verify that the provider or ISP has set up the required user and pension data before commencing integration testing. Once confirmed, integration testing will:
  • Configure the MaPS pre-production environment for the connecting organisation under test.
  • Drive the programme test dashboard harness to submit requests to the pre-production instance of PDP’s central digital architecture.
• An Azure DevOps (ADO) pipeline will orchestrate testing. Around 20 automated tests will be submitted in stages with a mandatory requirement for the provider or ISP to complete updates following the successful completion of stage 1 tests, and before stage 2 tests are run.
• Connection proving is the first part – this consists of a single find request.
• Stage 1 tests will only execute if connection proving is passed, confirming that the provider or ISP has successfully connected to the CDA.
• Stage 1 executes scripted test scenarios for users logging on to the test dashboard and submitting a mixture of find and view requests:
  • The provider or ISP needs to have already set up the supplied user data in their environment and configured matching rules and pensions.
  • Once the provider or ISP receives the requests via the pension finder service (PFS) their solution will attempt matching and will register the resources – later tests and automated log checks will verify this.
• If stage 1 is successfully completed, the provider or ISP must complete specific actions (as specified by PDP before integration testing starts) and inform PDP when they are completed.
• Stage 2 executes scripted tests to determine the success of the actions completed by the provider or ISP between test stages:
  • A view request will be submitted to confirm that full pension details are supplied after a possible match is promoted to a full match. The consent and authorisation service will be queried for the same user to check the number of resources registered.
  • Other stage 2 tests will query consent and authorisation resources to confirm they have been de-registered where required. Logs will also be checked to ensure the correct reason-code was recorded for those deletions.
• Figure 3: integration testing responsibilities

Checks to be performed by participants before integration testing connection proving

1. The holdername that is supplied as a part of PeI must be in the same case that was entered into the connection portal.
2. The find-requests and view-data APIs must return a 403 or 400 error if the client certificate in the request is invalid. If the client certificate is missing, then depending on the technology used by the pension's provider or scheme, a 403 or 400 error or a lower-level transport layer error (for example connection refused, reject handshake) should be returned.
3. Check the call to obtain PAT has the parameters in the request body and the header has Content-Type: application/x-www-form-urlencoded.
4. The ‘View data token jwt’ must have ‘kid’ value in the header for the dashboard to verify the signature.
5. Verify ‘type’ parameter is not included in the PeI registration call. If ‘type’ is included, it will return 400 error code.
6. Check the certificate is set up for consent and authorisation mTLS as a prerequisite to start connection proving.
7. Header names must be handled as ‘case insensitive‘ for all endpoints hosted on the resource server.
8. The correct URL for the ‘as_uri’ parameter should be: “https://sandbox.pensionsdashboards.org.uk/ig/token”

Business process

The high-level process is as follows:

1. The provider updates the connection portal to indicate that they have deployed the test crypto.
2. PDP implementation manager contacts the provider to confirm they have the prerequisites for integration testing in place.
3. Once confirmed, the PDP implementation manager requests a connection proving test be run by the PDP team. If issues are found, they will be communicated via Jira ticket, and if necessary, a support call will be arranged.
4. Connection proving is rerun until it is successfully passed. At this point the implementation manager will arrange a full integration testing session, which is booked for 3 hours.
5. At this session, the PDP tester runs stage 1 of integration testing. This continues until it passes, with issues diagnosed in the session if possible.
6. Once stage 1 of integration testing is completed, the provider will be asked to make updates to matches and then stage 2 will be run. This is again repeated until the stage passes.
7. More than one 3 hour slot may be necessary to complete integration testing.
8. The PDP implementation manager emails the provider their test report.
9. The provider’s test manager must then upload it to the connection portal.
10. PDP test manager approves the test report and the stage is completed.

Planning and scheduling of the tests

Providers are allocated an integration testing slot on a first come, first served basis when they reach this stage.

If a provider cannot utilise their window, the next organisation in the queue will be contacted to make use of the slot.

Environment reset

User accounts will be created within PDP’s consent and authorisation service and also on the dashboard.

In consent and authorisation, PDP will:

1. Create user accounts for our set of test users.
2. Register new resources against these user accounts.

In the dashboard PDP will:

1. Create user accounts for PDP test users.
2. Cache PeI lists against those accounts.

All accounts and resources will be cleared down between integration test runs so that each run is initiated from a known starting point.

Test data and test scripts

Integration test cases are detailed in the integration test cases Word document, which is included in this test pack.

Initial test data will have been created during system testing. Additional data required for integration testing is available in the ‘Integration test data’ Excel file. This can be accessed from the downloads section.

An open call will be held throughout the integration test window and data updates required by participants will be advised during that period.

Test evidence

The test report will be supplied by the PDP implementation manager in PDF format. It will specify:

• pass or fail for each test
• time and date of completion
• the provider code

The report will be sent to the provider who must then upload it into the connection portal.

Support

During the testing process, support will be available through the support hub. In the technical support area of the site, users will be able to report issues they are experiencing with PDP test and operational services that include:

• issues completing test requirements
• bugs and defects
• unexpected behaviours
• error messages
• other test related issues that you're unsure about

If users need to speak to a member of the PDP team to help resolve their issues, they should submit their issue through the support hub.

Context diagram

Figure 4: PDP integration testing context

Changelog

First published:19/12/2024

Last updated:23/01/2025