API Testing; Techniques You Should Be Using For Testing Your APIs
The API layer of an application is one of the more important components as it comprises most of the key business functionality of the application. It drives the business process as well as the integration with linked applications. With that it presents an excellent avenue to test and catch errors/bugs earlier on in your software development cycle, and reduce the overall risk of more expensive bugs late in the game.
As defined in a previous article, API testing (and automation) should cover a significant portion of your testing effort for any application as defined in the Test Pyramid seen below:
However, the key question now becomes, how do we achieve maximum efficiency in our API testing and automation effort while maintaining scalability, reusability and reliability? Here are some key techniques and types of tests you should adopt during your API testing phase.
API Validation Testing
This goes without saying, however it is the most important type of test you should have for APIs. This includes correct status codes (200, 201 for positive requests, 4xx, 5xx for negative) for valid/invalid requests, valid responses, valid requests/response headers etc.
This will also cover authorization and permissions testing as well.
Requests Chaining for Business Flow
Here, what we strive to do is as much as possible simulate the business flow of the application as much as you can using the APIs built. This will typically consists of a series of requests and responses linked together through chaining i.e. Using data from one response as part of the input for a subsequent request.
For example, let’s say you have a business flow that allows a certain user permission to upload a document, set the document to Pre-Approval but the user can’t approve it. Your scenario will consist possibly of a LoginIn request which returns a userID that can be passed into a GetPermissions request which returns the allowable permissions for that user. You can then call your UploadDocument request (with the userID and permissions), SetPreApproval request (with the documentUploadID), and subsequently attempt to approve the document via a ApproveDoc request (which should return a 401 error).
In the scenario above, you would have successfully simulated via API testing the business flow of logging in, uploading a document, and attempting to approve it using chaining. Multiple testing tools including ReadyAPI, Postman support chaining.
Data Driven & Boundary Tests
As the name suggests above this covers testing your set of APIs with multiple data scenarios and permutations and combinations. This is typically more important with APIs that input a considerable amount of varying datasets.
With data driven testing, you can simulate test data either through a test data generation function or a provided test data file generated outside of your testing tool. The idea being that any kind of data expected into the system is tested without necessarily having to go through the UI or other integrating applications.
Test coverage here typically includes boundary tests, invalid data types (special characters, null values etc), large int/string/long values, extreme future and past dates etc. These tests provide an excellent opportunity to ‘tighten up’ the APIs against certain worst case scenarios.
Performance
While this isn’t necessarily a full blown performance testing effort, API testing provides an early indication of potential performance issues. The general industry standard response time for APIs should be at about 200ms, and at maximum 1s.
While performing your API tests, it is good practice to have a response time assertion which enables you to catch sudden latency in the application or slow performing APIs. This could be tested in isolation or under load.
