API is one of the main systematically important software components.

It’s a ready web product, to some extent, and if it’s broken, the related applications that are built on it can be broken too.

[highlight dark=”no”]Therefore, you should test such components really thoroughly.[/highlight]

Further, we’ll analyze how we should use the main principles and testing methods while testing API.

1. Basic positive tests (executing a successful test script by default);
2. Extended positive tests, using additional parameters;
3. Negative tests with correct input data;
4. Negative tests with incorrect input data;
5. A process of destructive testing;
6. Security testing, accessibility testing, and authorization testing.

[highlight dark=”no”]A test script usually tests basic functionality and general criteria of API acceptance.[/highlight]

In the future, you can extend positive tests, to include additional parameters and complementary functionality.

Then goes a group of tests — to execute negative tests, whose execution may lead to a user expecting that software will properly interact with challenging scripts like entering a valid user (for example, an attempt to add a user’s name that already exists), and entering incorrect user data (a possibility to add a user name that contains the null value).

A set of destructive tests is a very deep type of negative testing when QA engineers try to break API, to tests its reliability (for example, by sending a huge request’s body, to load a system and try to break it).

Using test flows

Now let’s analyze three main types of testing flows that must be used while testing API:

1. Isolated testing of requests — launching one API request and related testing of response. These basic tests are in some way typical “bricks” that should be used to start testing API. And you shouldn’t continue testing if such tests aren’t executed.
2. A multi-stage flow that contains two and more requests is testing a set of requests in a form of typical user actions since some requests can depend on each other in a systematic way. For example, we need to execute the POST request that creates a resource, in turn, and returns a created ID in a response’s body. Then we take this ID, to check if this resource is present in a list of components that we have received with the help of the GET request. After this, we take PATCH, to update new information, and then create the GET request once again, to test this update. And finally, we need to delete this resource and then use GET again to ensure that a record that is used in a test is absent;
3. Combined testing of API and testing of the graphical web interface is mostly executing manual tests, during which we should ensure that information is holistic and there is correspondence between GUI and API.

Non-functional approaches to testing API

Automation and system security:

• You should check that API properly responds to correct authorization by using all possible methods: cookie files, token auth 2.0, and a digest;
• Check that API can reject all unauthorized calls;
• Check that API that you are testing contains a safe service break, all incorrect data are rejected in a request, and also there is rejection by default.

Load testing and stress testing:

• Test the time of API response and its delay;
• Find the spots where performance is limited and check that software works properly at a sufficient load and when the load is finished.