Application Programming Interface or API is simply an intermediary between two applications that help them to communicate with each other.
In simpler terms, when you use an online application, the application sends data to the server. The server then retrieves the data, interprets it, and sends the response back to the application by performing necessary actions needed to the data.
Furthermore, when the application receives the now-processed data, it interprets it further and presents it in a readable fashion.
So, where is API in all this? Well, all of these processes happen via an API.
The communication between your application and its database or a server is done via API.
Now that we know what an API is, in basic terms, let us look into what an API testing is?
API Testing, like the name suggests, is a software testing type that validates Application Programming Interfaces.
The main objective of API Testing is to check the functionality, performance, and security of the programming interfaces along with the reliability of the API.
Furthermore, testing the core business logic of the application is important for API Testing. This is because it drastically reduces the number of defects that could be found when conducting functional testing of the application at later stages while UI testing.
So, now that we know what API testing is, let’s find out why API testing is important.
To explain it simply, API Testing narrows down the probabilities of defect detection at later stages.
Since APIs need to be integrated with front-end applications, they are developed early. So, if we can find any defect from the early stages present in the core coding for the application, it is more efficient and effective.
When testing an API, we feed it with different sets of inputs and conditions. While doing so, we are ensuring that the same set of data won’t create any problem when the API is coupled with the application’s UI.
There are multiple tools available to automate API calls. These tools help to create an API testing automation suite.
Additionally, we can also use CI/CD(Continuous Integration/Continuous Delivery), where the API scripts can run after any changes made in the application.
Furthermore, this can help to identify any glitches making deployments and integrations error-free.
Here are a few other reasons why API testing is important.
The same set of APIs are used when the same application is made available for different platforms like mobile, desktop, etc.
Therefore, when we are testing API collection, we are also ensuring that the business logic will provide the same functionality across all the sets of platforms.
Yes, as bamboozling it may sound, API testing takes less time compared to functional testing.
Considering the same set of scenarios are to be tested, we just need to change the parameters for each call instead of filling out whole UI forms, like in the case of functional testing.
Also, with the help of API automation, we can test complete applications in a much lesser time.
In API testing, there are more test possibilities as compared to UI testing.
For example, if an application uses a token to login, attackers or hackers can change the token or send the request without a token.
In such cases, we can check how the API can respond during API testing.
So, API testing not only reduces security risks but also provides more flexibility in enabling better security.
As already explained, API is the bridge to fetch out data from the database with simple or complex processing on it.
With the help of various tools, we can easily check the time taken for an API to process and provide a response.
Furthermore, we can watch the response time and raise issues if an API takes unusual time to respond.
Now that we know what API testing is and its importance. So, let’s see how we can test APIs.
The first step to test APIs, before you can begin the actual test, is to ask about these to the API developer:
After gathering all of this information, you can start to build scenarios to test a particular API.
Furthermore, there are two types of testing that can be applied in every API testing:
Talking about positive testing, positive tests include the requests that the API developer would expect users would make in the normal course of using the application.
While designing a happy path test, it is important to include assertions.
One assertion should be that the correct response code is returned (often a 200 response). If the response includes a body, there should be an assertion on that as well.
For example, if a GET request is being verified, there should be an assertion that the body of the response contains the data that was expected with that record.
On the contrary, negative tests are those that make sure that any kind of error is handled correctly.
Here are some examples of negative tests:
Now that we have learned that most of the API testing is done through various scenarios, let us now find out how these scenarios can be created.
Let’s assume that we are given three APIs to test: GET, POST, and DELETE. These APIs are behind authentication.
API | Test Cases | Test Data | Assertions |
---|---|---|---|
URL/api/v1/customers/list/{{customerID}} | With correct endpoint and valid authorization token | URL/api/v1/customers/list/{{customerID}} | Status code: 200 |
With incorrect endpoint | URL/api/v1/customers/lists/{{customerID}} | Status code: 400 | |
Without authorization | – | Status code: 401 | |
With correct token of user of another role | TokenB | Status code: 401 | |
With invalid customer id | URL/api/v1/customers/lists/{{customerID}} | Status code: 404 | |
URL/api/v1/customers/create | Without payload | {} | Status code: 422 |
Without required field | { “Option1”: “somedata” } | Status code: 422 | |
With incorrect endpoint | URL/api/v1/customers/lists | Status code: 400 | |
Without authorization | – | Status code: 401 | |
With correct token of user of another role | TokenB | Status code: 401 | |
With valid payload | { “Option1”: “somedata”,“Required1: “requiredData” } | Status code: 200 Message: “Customer created successfully” | |
URL/api/v1/customers/delete/{{customerID}} | With invalid id | 435436546 | Status code: 404 |
With incorrect endpoint | URL/api/v1/customers/deleted/5 | Status code: 400 | |
Without authorization | – | Status code: 401 | |
With correct token of user of another role | TokenB | Status code: 401 | |
With valid id | 1 | Status code: 200 Message: “Customer deleted successfully” | |
With deleted id | 1 | Status code: 404 |
5. In URL section, Input “URL/api/v1/customers/create” and select HTTP method
9. In order to automate the collection here, you need to extract the customer id from the response.
7. Go to test tab and select, status code and contains string from snippet list
Note: I have shared happy path automation. You can add negative scenarios just like above and build a complete automation test suite.
So, I hope this helped you guys and please stay connected to learn more about other interesting topics.
Sign up to stay updated with the latest insights, news, and more.