© 2018 Capita Business Services Ltd. All rights reserved.

Capita Education Software Solutions is a trading name of Capita Business Services Ltd. Our Registered office is 30 Berners Street, London, W1T 3LR and our registered number is 02299747. Further information about Capita plc can be found in our legal statement.

API Testing Scenarios

General

Scenario - General

Expected result

Odata Metadata

Should be exposed correctly, read-only properties annotated as such, nullable/non-nullable marked accordingly, datatypes matching underlying model

Odata Swagger documentation

Can produce correct swagger documentation, only for the exposed/published endpoints

ExternalID vs ID

Should use ExternalID throughout the information domain message, internal ID property should never be exposed

Info domain spec

All messages should match the info domain spec exactly – structure and property names

Performance / Scalability

All endpoints perform singularly and under load within the performance parameters specified in the requirements.

GET

Scenario - Get

Expected result

No authentication/token

Returns 401 Unauthorised

No permissions to read

Returns 403 Forbidden

No ID supplied as key and No Filter

Either returns all records in the collection, all records with paging or validation error with details of filter required – depends on business requirement

Invalid ID (as key)

Returns 404 Not Found

ID supplied in the Filter where the ID does not exist

Returns an empty collection

Valid ID (as key)

Returns message body matching the structure of the info domain-specific message as a single record

$filter – correctly formatted:

- with values – equals and not equals

- with nulls – equals and not equals, on nullable and non-nullable fields

- with date in valid format – equals, gt, lt, within daterange (gt+lt)

- all properties in info domain which can be filtered using supported odata filter constructs

- applying multiple filters should be supported (and/or)

Returns message body matching the structure of the info domain specific message, filtered as per the filter options supplied.

Where multiple matches, always returns a collection of results - the collection may be empty

$filter:

- with date in invalid format

- with invalid property name

- all properties in info domain which cannot be filtered using supported odata filter constructs

Returns 400 Bad Request, with an appropriate error message

$select

- with valid property name

- all properties in info domain should be supported

Returns message body matching the structure of the info domain-specific message, but with only the properties in the $select list returned.

$select

- with invalid property name

Returns 400 Bad Request, with an appropriate error message

$orderBy

- with valid property name

- all properties in info domain should be supported

Returns message body matching the structure of the info domain-specific message, but with only the properties in the $select list returned.

$orderBy

- with invalid property name

Returns 400 Bad Request, with an appropriate error message

- test support for all other ODATA constructs:

o $search

o $count

o $skip

o $top

o $expand

o $format

Either - returns message body with content as per the applied construct or informs the caller that the construct is not supported.

POST

Scenario - POST

Expected result

No authentication/token

Returns 401 Unauthorised

No permissions to write

Returns 403 Forbidden

ID supplied

Returns 400 Bad Request, with an appropriate error message

Individually test with each of the mandatory fields not supplied

If fails - returns 400 Bad Request

With validation error

With multiple mandatory fields not supplied – multiple validation errors

If fails - returns 400 Bad Request

With multiple validation errors

Test for mandatory fields not supplied by user input (eg, learner id, fk refererence ids)

If fails - returns 400 Bad Request

With validation error

(scenario added as this is commonly missed validation)

Other validation errors as specified in requirements (eg, start date after end date) – test specific business validation

If fails - returns 400 Bad Request

With validation errors

Malformed model (incorrect structure)

Returns 400 Bad Request, with an appropriate error message

With correct model (matches info domain specimen message structure) and just mandatory fields supplied in correct format

Returns 201 Created with Location Header

With correct model and just mandatory fields supplied in incorrect format

Returns 400 Bad Request, with an appropriate error message

With correct model (matches info domain specimen message structure) and mandatory fields supplied and additionally with non-mandatory fields supplied in correct format

Returns 201 Created with Location Header

With correct model (matches info domain specimen message structure) and mandatory fields supplied and additionally with non-mandatory fields supplied in incorrect format

Returns 400 Bad Request, with an appropriate error message

PUT

Scenario - PUT

Expected result

No authentication/token

Returns 401 Unauthorised

No permissions to write

Returns 403 Forbidden

Invalid ID supplied

Returns 404 Not Found

Individually test with each of the mandatory fields not supplied

If fails - returns 400 Bad Request

With validation error

With multiple mandatory fields not supplied – multiple validation errors

If fails - returns 400 Bad Request

With multiple validation errors

Test for mandatory fields not supplied by user input (eg, learner id, fk refererence ids)

If fails - returns 400 Bad Request

With validation error

(scenario added as this is commonly missed validation)

Other validation errors as specified in requirements (eg, start date after end date) – test specific business validation

If fails - returns 400 Bad Request

With validation errors

Malformed model (does not match info domain specimen message structure)

Returns 400 Bad Request, with an appropriate error message

With correct model (matches info domain specimen message structure) and all fields supplied in correct format

Returns 204 No content

With correct model (matches info domain specimen message structure) and some fields supplied in incorrect format

Returns 400 Bad Request, with an appropriate error message

With correct model (matches info domain specimen message structure) and some fields supplied in correct format, other fields missing

Returns 400 Bad Request, with an appropriate error message

With correct model (matches info domain specimen message structure) and mandatory fields supplied and additionally with non-mandatory fields supplied in incorrect format

Returns 400 Bad Request, with an appropriate error message

PATCH

Scenario - PATCH

Expected result

No authentication/token

Returns 401 Unauthorised

No permissions to write

Returns 403 Forbidden

Invalid ID supplied

Returns 404 Not Found

Individually test with each of the mandatory field values (in the delta) not supplied

If fails - returns 400 Bad Request

With validation error

With multiple mandatory field values (in the delta) not supplied – multiple validation errors

If fails - returns 400 Bad Request

With multiple validation errors

Test for mandatory fields values not supplied (in the delta) by user input (eg, learner id, fk reference ids)

If fails - returns 400 Bad Request

With validation error

(scenario added as this is commonly missed validation)

Other validation errors (of fields in the delta) as specified in requirements (eg, start date after end date) – test specific business validation

If fails - returns 400 Bad Request

With validation errors

Previously stored property which would fail a validation rule if supplied, test for delta that does not include that property (only PATCHED fields are validated, not ALL fields)

Returns 204 No Content (patch succeeds)

With correct model for the fields supplied in the delta (matches info domain specimen message structure) and all fields supplied in correct format

Returns 204 No Content

With correct model for the fields supplied in the delta (matches info domain specimen message structure) and some fields supplied in incorrect format

Returns 400 Bad Request, with an appropriate error message

With correct model for the fields supplied in the delta (matches info domain specimen message structure) and some fields supplied in the correct format, other fields missing

Returns 204 No Content

DELETE

Scenario - DELETE

Expected result

No authentication/token

Returns 401 Unauthorised

No permissions to write

Returns 403 Forbidden

Invalid ID supplied

Returns 410 Gone

Valid ID supplied

Returns 204 No Content

BATCH

Scenario - BATCH

Expected result

All requests are valid

Message body contains individual responses, each with appropriate Success code for each request

All requests are invalid

Message body contains individual responses, each with appropriate Success or Error code/message for each request

Some requests are invalid

Message body contains individual responses, each with appropriate Error code/message for each request

GETCHANGES

Scenario - GetChanges

Expected result

Test supplying no minimum date (gt > x date)

Returns 400 Bad Request, with an appropriate error message (must supply a from date)

Test supplying a minimum date (and optionally a maximum date)

Returns message body containing a collection of results matching the structure of the info domain-specific message - the collection may be empty.

Should return results for all records in the information domain that have been added, updated or deleted within the date range supplied.

If no maximum date supplied, returns all records to current date/time.

RESOURCES

Related resources for