API Testing Details for Beggineers

API Testing Content :

An API (application programming interface) is essentially the “middle man” of the layers and systems within an application or software. 

API testing is performed at the message layer without GUI. It is a part of integration testing that determines whether the APIs meet the testers’ expectations of functionality, reliability, performance, and security. 

There are two broad classes of web service for Web API: SOAP and REST.

SOAP (Simple Object Access Protocol) is a standard protocol defined by the W3C standards for sending and receiving web service requests and responses. 

REST (REpresentational State Transfer) is the web standards-based architecture that uses HTTP. Unlike SOAP-based Web services, there is no official standard for RESTful Web APIs.

Here are 10 basic tips that you need to know for API testing:

1. Understand API requirements

Before testing your APIs, you need to answer these questions to thoroughly understand the API’s requirements:

1. What is the API’s purpose?

Knowing the purpose of the API will set a firm foundation for you to well prepare your test data for input and output. This step also helps you define the verification approach. For example, for some APIs, you will verify the responses against the database; and for some others, it is better to verify the responses against other APIs.

1. What is the workflow of the application; and where is the API in that flow?

Generally, APIs of an application is used to manipulate its resources in reading (GET), creating (POST), updating (PUT), and deleting (DELETE). Knowing the purpose of the API will set a firm foundation for you to well prepare your API testing data for input and output. 

In addition, this step also helps you define the verification approach. For example, for some APIs, you will verify the responses against the database; and for some others, it is better to verify the responses against other APIs.

For example, the output of the “Create user” API will be the input of the “Get user” API for verification. The output of the “Get user” API can be used as the input of the “Update user” API, and so on.

2. Specify the API output status

The most common API output you need to verify in API testing is the response status code.

Verifying if the response code equals 200 or not to decide whether an API testing is passed or failed is familiar to new API testers. This is not a wrong verification. However, it does not reflect all test scenarios of the API.

All API response status codes are separated into five classes (or categories) in a global standard. The first digit of the status-code defines the class of response. The last two digits do not have any class or categorization role.

There are five values for the first digit:

1. 1xx (Informational): The request is received and continues to be processed
2. 2xx (Successful): The request is successfully received, understood, and accepted
3. 3xx (Redirection): Further action needs to be taken to complete the request
4. 4xx (Client Error): The request contains the wrong syntax or cannot be fulfilled
5. 5xx (Server Error): The server fails to fulfill an apparently valid request

However, the actual response status code of an API is specified by the development team that built the API. So as a tester, you need to verify whether:

1. The code follows global standard classes
2. The code is specified in the requirement.

3. Focus on small functional APIs

In a testing project, there are always some APIs that are simple with only one or two inputs such as login API, get token API, health check API, etc. However, these APIs are necessary and are considered as the “gate” to enter further APIs. Focusing on these APIs before the others will ensure that the API servers, environment, and authentication work properly.

You should also avoid testing more than one API in a test case. It is painful if errors occur because you will have to debug the data flow generated by API in a sequence. Keep your testing as simple as possible. There are some cases in which you need to call a series of API to achieve an end-to-end testing flow. However, these tasks should come after all APIs have been individually tested.

4. Organize API endpoints

A testing project may have a few or even hundreds of APIs for testing. We highly suggest that you organize them into categories for better test management. It takes one extra step but will significantly help you create test scenarios with high coverage and integration. Take JIRA’s API, for example:

5. Leverage automation capability for API testing

Leverage automation capability for your API testing process as much and as early as possible. Here are some significant benefits of automating API tests:

1. Test data and execution history can be saved along with API endpoints. This makes it easier to rerun tests later.
2. API tests are stable and changed with care. An API reflects a business rule of the system. Any change in the API needs an explicit requirement; so testers can always stay alert of any changes and adjust them on time.
3. Test execution is much faster compared to Web UI test
4. API testing is considered black-box testing in which the users send input and get output for verification. Automation with a data-driven approach — i.e. applying different datasets in the same test scenario — can help increase API test coverage
5. Data input and output follow some specific templates or models so that you can create test scripts only once. These test scripts can also be reused throughout the entire testing project.
6. 
   

6. Choose a suitable automation tool

A further step to leverage the automation capability of API testing is choosing the most or a set of suitable tools from hundreds of options in the market. Here are some criteria that you should consider when choosing an API testing automated testing tool:

1. Does the tool support test the API/Web service types that your AUT (Application Under Test) is using? It will not make sense if the selected tool supports testing RESTful services while your AUT is using SOAP services.
2. Does the tool support the authorization methods that your AUT services require? Here are some authorization methods that your API can use:

1. No Auth
2. Bearer Token
3. Basic auth
4. Digest Auth
5. NTLM Authentication
6. OAuth 1.0
7. OAuth 2.0
8. Hawk Authentication
9. AWS Signature

7. Choose suitable verification methods

While the response status code tells the status of the request, the response body content is what an API returns with the given input.

An API response content varies from data type to size. The responses can be in plain text, a JSON data structure, an XML document, and more. They can be a simple few-word string (even empty), or a hundred-page JSON/XML file. Hence, it is essential to choose a suitable verification method for a given API.

Katalon Studio has provided rich libraries to verify different data types using matching, regular expression, JsonPath, and XmlPath.

Generally, there are some basic methods to verify an API response body content:

1. Compare the whole response body content with the expected information

This method is suitable for a simple response with static contents. Dynamic information such as date-time, increasing ID, etc. will cause trouble in the assertion.

1. Compare each attribute value of the response

For those responses in JSON or XML format, it is easy to get the value of a given key or attribute. Hence, this method is helpful when verifying dynamic content, or individual value rather than the whole content.

1. Compare matching with regular expression

Together with verifying individual attribute values, this method is used to verify data responses with a specific pattern to handle complex dynamic data.

Each verification method has pros and cons, and there is no one-size-fits-all option. You need to choose the solution that best fits your testing project.