A different way to test — API Testing

Categories: API | Testing |

What is API?

API (Application Programming Interface) is a collection of software functions and procedures, called API calls, that can be executed by other software applications.

What is API Testing?
API testing is mostly used for the system which has collection of API that needs to be tested. The system could be system software, application software or libraries. API testing is different from other testing types as GUI is rarely involved in API Testing. Even if GUI is not involved in API testing, you still need to setup initial environment, invoke API with required set of parameters and then finally analyze the result.
Setting up an initial environment becomes complex because GUI is not involved. In the case of API, you need to have some way to make sure that system is ready for testing. This can be divided further in the test environment setup and application setup. Things like database configuration and server start-up process are related to test environment setup. On the other hand, the object should be created before calling non static member of the class falls under application specific setup. Initial condition in API testing also involves creating conditions under which API will be called. Probably, API can be called directly or it can be called because of some event or in response of some exception.
Output of API could be some data or status or it can just wait for some other call to complete in a-synchronized environment. Most of the test cases of API will be based on the output, if API Return value is based on input condition.
These are relatively simple to test since the input can be defined and results can be validated against expected return value. For example, it is very easy to write test cases for methods like: int add(int a, int b). You can pass different combinations of int a and int b and can validate these against known results.

Does not return anything

For cases like these, you will probably have some mechanism to check behavior of API on the system. For example, if you need to write test cases for delete(ListElement) function you will probably validate size of the list, absence of list element in the list.

Trigger some other API/event/interrupt

If API is triggering some event or raising some interrupt, then you need to listen for those events and interrupt listener. Your test suite should call appropriate API and asserts should be on the interrupts and listener.

Update data structure

This category is also similar to the API category which does not return anything. Updating data structure will have some effect on the system and that should be validated. If you have other means of accessing the data structure, it should be used to validate that data structure is updated.

Modify certain resources

If API call is modifying some resources, for example updating some database, changing registry, killing some process etc, then it should be validated by accessing those resources.

You should not get confused with API Testing and Unit Testing. API testing is not Unit testing. Unit testing is owned by DEV Team and API by QA Team. API is mostly black box testing whereas unit testing is essentially white box testing. Unit test cases are typically designed by the developers and its scope is limited to the unit under test. In API testing, test cases are designed by the QA Team and its scope is not limited to any specific unit, but it normally covers complete system

API Testing Approach
An approach to test the Product that contains an API.

Step I:
Understand that API Testing is a testing activity that requires some coding and is usually beyond the scope of what developers are expected to do. Testing team should own this activity.

Step II:
Traditional testing techniques such as equivalence classes and boundary analysis are also applicable to API Testing, so even if you are not too comfortable with coding, you can still design good API tests.

Step III:
It is almost impossible to test all possible scenarios to user with your API. Hence, focus on the most likely scenarios, and also apply techniques like Soap Opera Testing and Forced Error Testing using different data types and size to maximize the test coverage. Some examples of the tools used are SoapUI and JMeter.

Main Challenges of API Testing can be divided into following categories
• Parameter Selection
• Parameter combination
• Call sequencing

API Framework
The framework is more or less self-explanatory. The purpose of the config file is to hold all the configurable components and their values for a particular test run. As a follow through, the automated test cases should be represented in a ‘parse-able’ format in the config file. The script should be highly “configurable”.

In the case of API Testing, it is not necessary to test every API in every test run (the number of API’s that are tested will lessen as testing progresses). Hence the config file should have sections which detail which all API’s are “activated” for the particular run. Based on this, the test cases should be picked up.

Since inserting the automation test case parameters into config file can be a tedious activity, it should be designed in such a way that the test case can be left static with a mechanism of  ‘activating’ and ‘deactivating’ them.

The following image represents the typical API’s Testing workflow.

Leave a comment