top of page
hand-businesswoman-touching-hand-artificial-intelligence-meaning-technology-connection-go-

A General - API Testing Checklist


In API testing, the first thing that comes to our mind is to validate the response code and body, but API testing is more than that. It's difficult to make a universal API checklist because APIs can be very diverse in their functionality, design, and implementation. They have different purposes, requirements, and constraints. Therefore, there's no one-size-fits-all checklist that can cover all the possible scenarios and use cases for API testing.


HTTP Status Code Verification:

The HTTP status code verification is the most basic test case while performing API testing. Validate that the API is returning the correct status code. Some common response codes are:


2xx - Success

200: OK: The Request succeeded

201: Created: The request succeeded, and a new resource was created as a result. (POST and PUT)

204: No Content: Response with status code and header but with no response body. (DELETE)


3XX – Redirection, further action is needed to complete the request.

301: Move permanently: Requested page moved to a new URL


4XX - Client Error, the request contains bad syntax or cannot be fulfilled.

400: Bad Request: Server unable to understand the request (Domain validation errors, missing data).

401: Unauthorized: Invalid authentication credentials.

404: Not found: The server is unable to find the requested page, which does not exist, or due to security reasons the service wants to mask it.

429: Too many requests, the user has sent too many requests in a given period.


5XX - Server errors

500: Internal server error

503: Service Unavailable, when the server is overloaded or down for maintenance.


Payload Verification:

Validate that the response body is not null or empty which is a basic test case. Verify the response payload—check valid JSON body and field types, names, and values. This check should include error responses.


Validate Response Headers:

Headers hold additional information about the response. The content-type header tells what type of content the body contains. If the content-type header is blank or missing, then the browser attempts to display the source most appropriately. This can cause a security threat. The content-length in the header tells the size of the response body.


Schema Validation:

Schema validation ensures that the response format is the same as the expected one. Validations rules are like data in the key/value pair. The key should be in double quotes and must be a string, the response includes arrays and objects. If the schema is of object type, then if we try to send a non-object request, we should get an error. Similarly, we can specify min items and max items validation on the schema. JSON schema validation can be done using any JavaScript library.


Authorization:

To check security and access controls to see if the API includes any vulnerabilities. There are multiple types of authentications available such as basic auth, API key, Bearer token, and OAuth for security purposes. A few things can be validated for authorization like auth token expiration is set or if ‘Bearer’ needs to be appended with the token but still token is working without it. Ensure API refuses all unauthorized calls.


Performance Testing:

API performance testing evaluates how an API performs under certain conditions. In general, there are two broad categories of API performance testing: functional testing and load testing. We can check the response load time, and response size using Postman. In automation testing, custom methods can be written to perform these kinds of validations. Ideally, you should check:


The number of concurrent server connections it can take before failure.

Concurrent user load in batches of 10, 50, 100, 200, 500, and so on.

The expected throughput and response time for different user loads.

The maximum queries or number of calls executed per second.

Continuously testing the API helps you identify performance issues to ensure there are no failures, or speed issues when the application is released to end-users.


AAA Rule (Arrange, Act, Assert):

The famous AAA pattern of testing is to arrange all necessary preconditions and input, act on the test, and assert the expected result. Without good assertions and tests, it is impossible to have full confidence in API behavior. Assertions are checked every time a test runs.


Negative Test Cases:

Negative testing is an important part of API testing. For example, attempt to create a resource with a name that already exists, or try to delete a resource that does not exist. Try to delete the user configuration without permission. Attempt executing API with an expired token or try to use an unsupported method.


Destructive Testing:

This technique is used to intentionally fail the API to check the robustness and identify points of failure. A malformed request payload, overflow parameter values, and empty payloads.


Contract Testing:

Testing the API against a predefined contract or specification. The contract defines the expected behavior of the API, including the input parameters, expected output, and error handling.


Integration Testing:

As the API layer is the intermediate layer between the presentation layer and the data access layer, ensure that integration between third-party or internal services works properly.


Conclusion:

An API is an Application Programming Interface that allows various components to communicate, share data, and achieve other functionality. APIs are the primary way that modern web applications communicate and share data. APIs have such a key role in achieving integration and interoperability between many types of applications, the correctness, performance, security, and reliability of APIs must be tested.

421 views0 comments

Recent Posts

See All

Exception Handling in Selenium Webdriver

What is an exception? An exception is an error that occurs during the execution of a program. However, while running a program, programming languages generate an exception that must be handled to prev

Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page