Home

Welcome to the gpconnect-provider-testing wiki!

This project is an automated test suite designed to validate a providers implementation of the GP Connect API against the core requirements of the GP Connect API specification.

The tests are written in a BDD format making the tests easy to read for everyone including non technical users. This was done so testing and solution assurance teams could write and review the tests making the testing solution more accessible to a wider audience. Underlying the BDD tests are the code steps which are written in “.NET” and Specflow using the standard “.NET” Fhir library.

Automated Testing

The automated test suite is designed to test the provider in the following ways:

• By sending a variety of valid requests to the provider system and validates that data returned by the provider system matches the requirements of the specification and GP Connect fhir profiles.
• By sending a large number of different invalid requests to the provider system and validate that the providers system returns errors which match the expected error response behaviour as set out in the GP Connect project specification.

Manual Testing Required

Due to differences in the provider systems and the number of optional fields within the Fhir resources there needs to be additional manual testing performed along side the automated test suite:

• The test suite can only test that the content returned is valid and can not test that all the data available in the provider system is included in the response message. Checking that all available information within the providers system is included in the response message should be tested manually.
• Mappings – as all providers are different they may have different value sets within their system to the ones included in the GP Connect and standard Fhir profiles. Any testing of the mappings from a provider specific value set to the GP Connect values sets must be performed manually to make sure that all possible values map to valid GP Connect value set values.
• Underlying functionality - the expectation is that the capability of the GP Connect api will match the capability of a user using the provider system directly. For example if the provider system allows multi slot booking in their appointment booking system then this should also be possible through the GP Connect API. The way this is achieved in the providers system is up to the provider and must be tested manually as it is not possible to make the automated test suite generic for all providers but also able to test each providers differences or underlying processes.

---

Test and Development Approach

The recomended test and development approach which will work best with the automated test suite is set out in individual wiki pages linked below:

Test Approach - Access Record

Test Approach - Foundations & Appointments