API Testing Techniques !

What is API?

An 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 initial environment become complex because GUI is not involved. In case of API, you need

to have some way to make sure that system is ready for testing.

This can be divided further in test environment setup and application setup. Things like database should be configured, server should be started are related to test environment setup. On the other hand 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.

Test Cases for API Testing:

The test cases on API testing are based on the output.

• Return value based on input condition

Relatively simple to test as input can be defined and results can be validated.

Example: It is very easy to write test cases for int add(int a, int b) kind of API. You can pass

different combinations of int a and int b and can validate these against known results.

• Does not return anything

Behavior of API on the system to be checked when there is no return value.

Example: A test case to delete(ListElement) function will probably require to validate size of

the list or absence of list element in the list.

• Trigger some other API/event/interrupt

The output of an API if triggers some event or raises some interrupt, then those

events and interrupt listeners should be tracked. The test suite should call

appropriate API and declarations 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.

• Modify certain resources

If API call is modifies some resources, for example makes update on some database, changes registry, kills some processes etc, then it should be validated by accessing the respective resources.

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 that are possible to use 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.

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.