RestAssured #7 - API Testing Scenarios
Introduction
API testing should be done thoroughly since it impacts the overall application, both the front end and the back end. In the event of poor API testing, the back end will have garbage data, which is not useful. If the response to the user input was not tested well enough, the front end will have issues if the user makes a mistake, intentionally passes invalid values, or enters garbage data.
In this article, we are going to see what different scenarios need to be covered specific to API testing.
Schema Validation
Schema validation in API testing refers to the process of ensuring that the structure and data types of the response from an API endpoint match a pre-defined schema.
The schema defines the expected response format, including the types of data that should be present and their relationships to each other.
This can include things like
the number and types of fields in a JSON object
the structure of an XML document -> The type of schema is correct (JSON Object or JSON Array).
The required/mandatory parameters are present.
By validating the response against the schema, developers can ensure that the API is returning the expected data and that it is in a format that can be easily parsed and used by clients.
Test Coverage
API test coverage is said to be good if it covers
all functional aspects of the software application,
the technical aspects of the API,
versioning,
error logging,
request and response headers
request and response parameters,
the data including invalid data and data injection (and a few other aspects of security testing), and finally the performance.
Header Testing
Header testing is an important part of API testing since it has the metadata information, authorization token, content type information, the expiry of the token, and many more aspects that are crucial for the API to work efficiently.
Request Header
Request headers play a major role in making sure that API works as per the technical and functional aspects. Request headers can be exploited by a hacker, so it is very important from the security testing perspective.
Below are different validation that can be performed on the request header
Correct Header
Missing Header
Incorrect Header
Unsupported Type
It is important to test the request headers to ensure that the API is accepting the expected headers, they are well formed, and that the API can handle the request headers properly to provide the expected outcome.
When testing request headers, several things can be checked:
Content-Type: Ensure that the API is accepting the correct Content-Type header in the request, such as "application/JSON" for JSON data or "application/XML" for XML data.
Authorization: Verify that the API is properly handling the authentication and authorization headers in the request, such as an API key or a token-based authentication scheme.
CORS headers: Check that the API is properly handling cross-origin resource sharing (CORS) headers in the request, such as "Origin" and "Access-Control-Request-Method".
Cache-Control: Ensure that the API properly handles cache control headers in the request, such as "Cache-Control: no-cache" or "Cache-Control: max-age=3600", to control how clients should cache the response.
Accept-* headers: Check that the API is handling Accept-* headers, such as "Accept-Language" or "Accept-Encoding", which specify the client's preferences for the response.
Custom headers: Verify that the API is handling any custom headers that are being sent in the request, like "User-Agent" or "Referer".
Request Size Limit: Ensure that the API is handling the size limit of a request, and returning the appropriate error response on exceeding.
Response Header
Response headers are crucial for the success of the API. The following sections cover a few examples.
Supported Type
Response Code
It's important to test the response headers to ensure that the API is returning the expected headers, they are well formed, and they are doing the intended job.
When testing response headers, several things can be checked:
HTTP status codes: Ensure that the API returns the correct HTTP status code for each request, such as 200 for success or 404 for not found.
Content-Type: Validate that the API is returning the correct Content-Type header, such as "application/JSON" for JSON data or "application/XML" for XML data.
Authorization: Verify that the API is properly handling authentication and authorization headers, such as an API key or a token-based authentication scheme.
CORS headers: Check that the API is properly configured to handle cross-origin resource sharing (CORS) headers, such as "Access-Control-Allow-Origin" and "Access-Control-Allow-Methods".
Cache-Control: Ensure that the API is properly setting cache control headers, such as "Cache-Control: no-cache" or "Cache-Control: max-age=3600", to control how clients should cache the response.
Security headers: Verify that the API is setting security headers, such as "X-XSS-Protection" or "Content-Security-Policy" to protect against cross-site scripting (XSS) or other security vulnerabilities.
Content-Encoding: Check that the API is returning the correct Content-Encoding header, such as "gzip" or "deflate" if the response is compressed.
Content-Length: Verify that the API is returning the correct Content-Length header, which indicates the size of the response body.
Location: Check the Location header in case of redirects, to ensure it's providing the correct location for redirects
Request Body
It's important to validate the request body to ensure that the API is receiving the expected data, it's well-formed, and that it's able to handle the data and provide the expected outcome. Below are things that can be checked for validating the request body -
Data Types - Ensure that the data types of the fields in the request body match the expected data types, such as a string for a name field or a number for an age field.
Required Fields - Remove the required fields from the payload and check the API response. The API should show appropriate error messages if the required fields are missing.
Format Unsupported - Send a text format as a payload and check the response. Only supported formats should be allowed by the API.
Special Characters - Send special characters in the payload in place of the string data type and check the API response.
Very Long Strings - For a name or any other string, pass in a very long string in the payload and check the API response. The API should not allow a string that is greater than the column size in the database.
Invalid Method - Use POST instead of PUT and check if the API responds to the request. The API should throw an error if the endpoint does not have the required access method, which is given in the API documentation.
Invalid Value - For integers values, pass in decimal values. For Boolean values, pass in a string like “true” (in quotes).
Incorrect Data Type - Instead of integers, pass in string values and check the API response. The API should throw an error appropriately.
Empty Data/Object - Pass in an empty JSON object as a payload and check the response. Also, pass in an empty string to check the API response. The API should not allow these inputs. Empty strings will ultimately end up in the database if the operation is adding new data.
Null - Send null as values in the payload and check the response. The API should show appropriate error messages.
Redundant Fields - Pass in redundant fields, such as fields that are not required. Also, pass additional fields that are not in the definition of the payload and check the response. The API should not allow additional fields. The redundant fields, if not in the definition, should not be allowed.
DELETE Already Deleted Entity - This is more specific to the DELETE method. Once the entry is deleted from the database, hit the same API again and check the response. The API should respond with a message that the entity does not exist.
Duplicate Check - For add operation, you should check if the duplicate check is enabled on the API endpoint or not, based on the business requirements. For example, the email ID and the phone number should be unique for contacts. You also need to check if the update operation is duplicating the record in the database.
Response Body
The response body is the validation of the expected data based on the input, which is called the actual data.
Actual Data vs. Expected Data - Let’s say you are requesting a list of contacts. The response would be to have a list of contacts with the fields based on the API definition.
Limit/Size/Pagination/Sorting - You need to make sure that the API returns the data in the specified format. There is also pagination. The size of the response should also be checked since it directly impacts the performance of the API.
API Version Testing - This category contains backward compatibility tests. If the endpoint changes, the old one should not be removed, but when the user hits the old endpoint, it should redirect to the new endpoint.
Reference - Learn API Testing: Norms, Practices, and Guidelines for Building Effective Test Automation (Book)