Run end-to-end testing¶

The integration environment accurately reflects hub behaviour in the production environment. You can use the integration environment to test complete user journeys, both success and failure scenarios.

We advise you to do end-to-end testing in the integration environment as part of your continuous integration pipeline. For more information, see Testing code in the Government Service Design Manual.

You must provide a full demonstration of all user journeys as part of your Stage 4 gate review.

Important

If you carry out penetration testing (pen testing) on your end-to-end system, you must not extend this to the hub domain. You must only run penetration tests on your own system. If you think you have a valid reason for running penetration tests in the hub domain, you must first contact GOV.UK Verify support at idasupport+onboarding@digital.cabinet-office.gov.uk.

This diagram shows the end-to-end testing flow. See below for explanations.

End-to-end testing in the integration environment

Setup for end-to-end testing¶

The integration environment is not accredited to use real user data, and it has no links to real identity providers. Carry out business analysis to identify user identities that cause potential problem scenarios during matching. Then, in the user administration application programming interface (API), create test users that will test these scenarios. You must also add the test users to your local matching datastore in the integration environment.

A test identity provider contains:

the user administration API – you should have submitted your credentials when you requested access to the environment
a connection to the hub in the integration environment, which is used for end-to-end testing – no authentication credentials are required

Setup for end-to-end testing involves the following procedures:

create test users

view test users

delete test users

Create test users¶

This procedure describes how to create test users in bulk and load them into the test identity provider. You must add the same test users to your local matching datastore in the integration environment.

Make an HTTP POST to the user administration API with a JSON document containing an array of user data. For example:

curl --user '{username}:{password}' -H 'Content-Type: application/json' -d @create-user.json https://idp-stub-integration.ida.digital.cabinet-office.gov.uk/{idp-name}/users

where:

username and password are your credentials for managing test users
idp-name is the name of the test identity provider. Completing a journey in the integration environment will help you find this. On the identity provider page, you’ll see your designated idp-name in the url.

create-user.json is the name of the file containing an array of test user data in JSON format, for example:

[{
    "pid": "00754148-902f-4d94-b0db-cb1f7eb3fd84",
    "username": "user1",
    "password": "password",
    "firstName": {
        "value": "Fred",
        "verified": true
    },
    "gender": {
        "value": "MALE",
        "verified": false
    },
    "dateOfBirth": {
        "value": "1970-01-01",
        "verified": true
    },
    "address": {
        "verified": true,
        "postCode": "WC2B 6NH",
        "lines": [
            "Aviation House",
            "London"
        ]
    },
    "levelOfAssurance": "LEVEL_2",
    "surnames": [{
        "value": "Smith",
        "verified": true
    }]
}]

Possible values are shown in the following table.

Attribute	Value
levelOfAssurance	Level of assurance must be one of the following values: LEVEL_X LEVEL_1 LEVEL_2 LEVEL_3 LEVEL_4
firstName surnames dateOfBirth	These attributes can contain the following fields: value (variable type) DateTime from (the time when this value started - eg changed name to this - Optional) DateTime to (The time after which this value ended - eg changed name from this - Optional) boolean verified
gender	Gender must be one of the following values: FEMALE MALE NOT_SPECIFIED
address	Address consists of: boolean verified DateTime fromDate DateTime toDate (Optional) String postCode (Optional) List<String> lines String internationalPostCode (Optional) String uprn (Optional)

View test users¶

To view existing test users, GET the users resource from the relevant test identity provider. For example:

curl --user '{username}:{password}' https://idp-stub-integration.ida.digital.cabinet-office.gov.uk/{idp-name}/users

where idp-name is the name of the test identity provider.

The test users are returned in JSON format. To view the page you must provide your credentials for managing test users. You create the credentials by submitting the environment access form.

Delete test users¶

To delete test users from the test identity provider, POST a JSON document to the user administration API containing the usernames you want to delete. For example:

curl --user '{username}:{password}' --data '{"username": "user1"}' -H 'Content-Type: application/json'  https://idp-stub-integration.ida.digital.cabinet-office.gov.uk/{idp-name}/users/delete

where:

user1 is the name of the test user you want to delete
username and password are your credentials for managing test users
idp-name is the name of the test identity provider

Run end-to-end tests¶

As a minimum, test the following end-to-end user scenarios:

authentication success and authentication failure
match and no-match
all the possible outcomes of your matching service, including Cycle 3 and user account creation, if implemented

Tear down¶

After each integration test run, we recommend that you delete the test users. Set up each integration test run with newly created test users.

When you’ve successfully completed testing in the integration environment, you must provide a full demonstration of all user journeys. This is one of the outputs required at this stage before moving on to Stage 5 Production Onboarding.