API Testing
There are many types of software testing. To name a few, there are:
In today’s article, we’re going to look closer and talk about testing one of the most important components in a software system — Application Programming Interface (API).
An API is a computing interface for multiple applications to interact with one another. It is the bread and butter of any computing system which establishes the communication protocols for interaction in the software world.
Since APIs interact with other systems, it is important to ensure that there are proper tests in place so that they work well and don’t break communications with their interfacing systems. After all, web services testing forms the central layer of the testing pyramid.
But before we do anything, we need to know what we have! Hence, the following information are important:
API specifications
A single source-of-truth document for any system which every team is required to maintain from the start of the development phase until the project releases. It should contain the entire list of APIs used in a particular system version. All this information will help us craft all potential positive and negative flows to be covered in our testing.
API versioning
It is inevitable that there will be changes to the list of APIs as the development work progresses. Thus, versioning helps to clearly distinguish the API(s) from different releases and in turn to what they do. To the QEs, every version of the API spec defines a set of tests to be executed with the APIs. Brand new APIs are to be tested to ensure they match the requirements and are then added to the regression suite, while the modified APIs to match their relevant changes. It is likely that multiple versions of APIs exist in the same system, and we have to validate whether each version does function as per requirement.
API security
Security is a vital and wide-ranging topic in API testing that is applicable to both public and private APIs. The first thing we should verify is to see if all our APIs are using HTTPS. Next, Any API that requires authorisation must have the relevant verifications and appropriate response in the event of unauthorised access. Lastly, it is also recommended to test for non-idempotent API operations (i.e. POST) as they cause changes in the data. We need to test that such operations produce the expected result as per the requirements.
So exactly when and how do we start API testing?
The best time to start API testing for Agile projects is when the API spec draft becomes available and only minor changes are expected. We can make an API call and get its response using cURL (note: we’ll be using the OneMap API in our discussion):
However, this method is prone to human errors and we don’t recommend it for scalable API testing.
Similar to our foray into mobile automation testing, if you want to automate API testing, there are multiple open-source libraries which allow us to call APIs. Here’s a few examples for NodeJS framework:
- request: (npm install request)
A very popular library for making HTTP requests that is low-level and easy to use. - supertest: (npm install supertest)
An API testing library with a high-level of abstraction.
Along with a library to call APIs, we also utilise a test framework (jest) to manage our tests in a more readable format. Without further ado, let’s take a look at writing automated API tests using supertest + jest (we’ll be using the OneMap API in our discussion).
Firstly, install the supertest library. Once installed, import supertest into the code and initialise a variable with an endpoint URL.
The most basic happy path flow is to successfully call the API with valid inputs and receive a success response:
We can include many negative test cases in our API testing. For OneMap /convert API, query parameters are mandatory. So, we can write negative test cases such as:
- No valid query parameters
- Few missing query parameters
- Incorrect parameter type
- Empty or white-spaced parameters
We can also include negative tests for authorisation and error codes to ensure coverage and error handling. Our recommendation is to be exhaustive with API testing and since the tests are executed at the service-level, they execute swiftly!
To get the full code for the API testing, please click here.
In API testing, we only focus on one API at a time. We take our testing microscope and zoom all in into each API to understand whether it satisfies requirements, performs data validation and sanitisation, contains secure authentication (if required), and follows the web services standard.
Now that you have seen what API testing is, we hope you have learned something from this post. We’ll look into advanced techniques in a future blog post. If you have any comments/questions for us, feel free to leave a comment below.
Take care and stay safe! 😉
- Merlin 💛
