If you’re looking to make quick and easy API calls to validate that your API is responding as it should, you’ve come to the right place.
Hi! I am “Senior Technology Fellow” and today we are gonna talk about the best practices and techniques to perform API testing.
What is an API?
In basic terms, APIs just allow applications to communicate with one another.
When people speak of “an API”, they sometimes generalize and actually mean “a publicly available web-based API that returns data, likely in JSON or XML”. The API is not the database or even the server, it is the code that governs the access point(s) for the server.
Why would we need an API?
Imagine the following scenario: You (as in, your application, or your client, this could be a web browser) wants to access another app’s data or functionality. For example, perhaps you want to access all Twitter tweets that mention the #idelsoft hashtag.
You could email Twitter and ask for a spreadsheet of all these tweets. But then you’d have to find a way to import that spreadsheet into your application; and, even if you stored them in a database, as we have been, the data would become outdated very quickly. It would be impossible to keep it up to date.
It would be better and simpler for Twitter to provide you a way to query their application to get that data, so that you can view or use it in your own application. It would stay up to date automatically that way.
An API brokers access to a different application to provide functionality or access to data, so data can be included in different applications.
API testing focuses on what’s known as the business layer of the application, meaning the testing methods will be entirely different compared to the standard GUI testing. So instead of using keyboard strokes and mouse clicks as standard input, in API testing we may need to use some other testing patterns, use some testing tools or our own code in order to examine these APIs under test. You need to validate the responses (output) from these APIs in order to verify that they are working, or not. To know what to look for, you will need be aware of the response that an API generates.
An API response will be:
- A status message/Boolean value (for example, success/error, or true/false etc.) which will display the status of the API call. It will also act as a flag (true/false), on which the Presentation layer or the Database layer will be then updated.
- A set of data which is to be passed on to a subsequent API, or to the GUI or to the Database.
What to Test for in APIs?
- Functional: This is where you look for the API response based on the input provided. Check whether the actual response matches the response expected.
- Performance: Here, you need to be aware of the API’s response time. Occasionally, it takes a long time to get a response from the API. This can be due to a performance issue related to the API’s design.
- Security: Checking whether any sensitive data passing onto the API has been encrypted, or not, is part of this testing. For example, you may want to check an API that is responsible for generating a dashboard report on a home page. In order to access the dashboard API, you may need a token that would have been generated as a response from the login API previously run. This token should be in encrypted format. You can also check if there is any HTTPS encryption in place.
- Reliability: You can check whether the API gives you prompt response everytime you test for different configurations (for example, different environments, various user logins etc.) You can check if the output returns any exception handling errors, timeout errors etc. which will point to the reliability of the API. Part of reliability testing you can also check whether the response data is structured properly. Usually API response will be structured in JSON or XML format.
- Negative Testing: Here the aim is to provide invalid input data to the API and check how the output data behaves. API should handle the errors properly. It should provide valid, meaningful error messages for every negative input conditions. You can also test the behaviour of the API if empty input data is used for some arguments. You can also look out for any unused flags, missing/duplicate output values for different input data.
What does an API test case look like?
The below components should be included in a API test case document.
The API URL
This is the HTTP request for invoking a particular API. Take, for example, an API for login functionality. If its URL structure is Mobile/User/Login and your domain URL is http://twitter.com, then the API URL to invoke the API from browser/tools will be http://twitter.com/Mobile/User/Login
In the case of RESTful APIs, they use HTTP methods to classify the APIs based on the type of call made to the server. For example, POST, GET etc. The POST method sends data to the server while the GET method fetches the data back from the server.
This defines the structure, or the model of input data, which is to be supplied to the API. For example, if we take the above Login API we can use the below data structure:
Request Sample Data
Request Sample contains the actual input data which is passed on to the API as a payload. You can have as many test cases as you want based on this sample data. For the above login scenario, the sample data might look like this:
This represents the response code of the API request. 200 OK should be the response Code of a successful API request. There are other Response codes such as 400 Bad request, 401 Unauthorized, 403 Forbidden, 404 Not found, 500 Internal Server Error etc. It would be useful if you could note down the Response Code of the API from the output console of the API testing tool.
Response Result Message
For each input, there might be different API output success messages. You need to figure out the corresponding response messages and document them in your test cases. Some common messages for Login API will be: SUCCESS, INACTIVE_ACCOUNT, INVALID_PASSWORD, USER_NOT_FOUND, INVALID_DEVICE_ID, ERROR
Response Result Sample
This is the output data for each of the input data combinations. You will need this data to be able to validate against the actual output from the API results. A sample for a successful Login operation is given below:
Tips for API Testing
- Understand what each API is used for in the application. Without understanding the use of a particular API, it will be difficult to document sufficient test cases for it.
- When writing test cases for different input conditions, make use of testing techniques such as Boundary Value Analysis and Equivalence Class Partitioning.
- Properly document the input parameters and response of the API for each of the test cases so that testing can be carried out in a structured way. It’s also important that you order your test cases in such a way that one follows the other. For example, for testing CRUD operations, you need to write the test cases in the order Create, Update and Delete.