preface

This article also introduces testing tools such as cURL and Postman. But these are all basic things, and there are a variety of online tutorials, so I won’t repeat them; The main thing here is how do you handle API testing for complex scenarios

 

API testing process

  1. Preparing test data (this is an optional step and not required for all API tests)
  2. Initiate a request to the API under test using the API testing tool
  3. Verify the response of the returned result

 

How to handle API testing for complex scenarios?

Test scenario 1: The service operation under test is performed by multiple API calls

background

A single front-end operation may trigger a series of back-end API calls, in which case the API test case is no longer simply a single API call, but a series of API calls

 

Existing condition

  • There are cases where the latter API needs to use the former API to return results
  • You need to decide which API to call next based on the results of the previous API

 

There is a problem

Efficiently get the order of API calls triggered by a single front-end operation

 

Solve the above problem ideas

  1. The API call sequence triggered by a single front-end operation can be captured by network monitoring methods, such as packet capture tools such as Fiddler and Charles
  2. Call order can also be obtained through user behavior logs and big data means

 

Test Scenario 2: Third-party dependencies during API testing

background

  • There are dependencies between apis. For example, the object under test is API A, but API A calls API B internally. If API B is unavailable in the environment under test for some reason, the test of API A will be affected.
  • In a singleton architecture, this problem is usually only encountered in scenarios involving third-party API integration, so it’s not a serious problem. However, in a microservice architecture, the dependency problem of API coupling can be severe.

 

The core idea of problem solving

Enable the Mock Server instead of the real API

 

Test scenario 3: Testing asynchronous apis

What is an asynchronous API

It returns immediately after the call, but the actual task is not really done, instead the API needs to be queried or called back later

 

There are two main parts to testing asynchronous apis

  1. Test the success of the asynchronous call by checking both the return value and whether a background worker thread was created
  2. Tests whether the business logic handling of the asynchronous invocation is correct

 

Test the business logic complexity of asynchronous invocation

Because asynchronous apis often occur on slow operations such as database I/O, message queue I/O, etc., tests often need to verify values in the database, message queue, etc., which requires the ability of the test code to access and manipulate the database or message queue. In real engineering projects, these capabilities are typically provided at the level of the test framework, which requires the API test framework to include the corresponding utility classes to access and manipulate databases or message queues, etc