This article was originally published at: kapeter.com/post/35

1 introduction

In the process of using Node to develop HTTP interfaces, the author found that when the number of interfaces increases and the interfaces depend on each other, the interface testing process will become very tedious and error-prone. So how do you effectively and comprehensively test your interfaces?

Through practice, the author found that Postman could be used to automate integration testing and document the practices.

2 Postman configuration

Postman is an API platform for building and using apis that simplifies every step of the API life cycle and simplifies collaboration, allowing users to create better apis faster. The following is a brief introduction to its use process.

2.1 Project Configuration

A complete system often has many modules and interfaces, so a Collection is recommended for easy management. Similarly, we can also divide modules into folders to make the whole project structure clearer. This setup will also facilitate subsequent integration testing.

If the project is multi-person, you can also create a Team Workspace and put the project into this Team space so that the Team members can use it together. Note that the free version of the team space is limited to three people, if there are a lot of team members, you have to pay to use it.

2.2 Environment Configuration

Postman supports setting environment variables and global variables. The difference is that environment variables only apply to the current environment, while global variables apply to the entire workspace. I generally use environment variables myself.

The most common scenario for environment variables is setting URL prefixes. A typical development interface will have three environments with different urls:

  • Local environment:http://127.0.0.1:xxxx(port number)
  • Pre-release Environment (Beta) :https://beta-api.xxx.com
  • Production formal environment:https://api.xxx.com

Without using the environment variable, suppose you want to test a interface: / user/info, three environment you need to create the request (request), such as the local environment is written as: http://127.0.0.1:xxxx/user/info.

What do you do with environment variables? First create a local test environment (local) and create a BASE_URL variable in it. Then change the URL of the request to {{BASE_URL}}/user/info. Postman will replace this position with the value of the variable when making the request. In this way, a single request can correspond to multiple environments.

In addition to the environment Settings, sometimes the interface may also be connected to a third-party unified login, so you need to set the Cookie value. This can be set on the header of a single interface, but is generally done globally. At the bottom of the Save button is a small line that says “Cookie” in orange. Click on it and you can set it.

As we all know, the scope of cookies is the domain itself and all subdomain names under the domain. Therefore, we need to set the domain first, and then set the corresponding Cookie under the domain name. Since the sub-domain name can call the Cookie of the parent domain name, it is necessary to set cookies of the local environment and online (Beta + Production) environment.

2.3 Interface Configuration

With everything in place, we can configure the interface Request. This is also the most commonly used interface. The top is the request information and the bottom is the response data.

Specifically, the request can set a variety of request methods (method), can set routing parameters (Params), some request methods, but also need to set the request content (body). The body of the request also supports a variety of data formats. I use JSON format here, and the corresponding content-Type is Application/JSON.

In addition to the general configuration above, Postman also supports setting up pre-Request scripts and Tests scripts, which will be explained in the next section.

3 Integration Test

The previous section explained how to use Postman to initiate a request and get a response, and during development, these features meet most of the requirements. However, in the testing phase, the linkage of multiple interfaces is involved. For example, interface B depends on the response data of interface A, and interface C depends on the response data of interface B. At this time, the tester needs to manually copy the response data of interface A to the request of interface B, and the testing process is very tedious. Next, I introduce a method to concatenate these interface requests.

3.1 Test Script

The basic idea is to set environment variables. For example, the display notification interface (/notice/show/:id) relies on the create notification interface (/notice/create), Change the URL of the display notification interface to {{BASE_URL}}/notice/show/{{notice_id}}, and set this to a different ID to invoke. The difference is that the value of BASE_URL used above is a certain constant, whereas notice_id is a value that changes dynamically as the interface is created, and how the environment variable is set dynamically is key.

This is where the Postman pre-request Script and the Tests Script are used.

A pre-request Script is literally triggered before a request is made. Common usage scenarios include setting a current timestamp parameter to the interface. Tests scripts are triggered after a request and are commonly used in scenarios such as testing whether the current interface results are correct. Both scripts are written in JavaScript and cost the front-end engineer nothing to learn, which is great.

Scripts can be set not only for requests, but also for collections and folders, and their scripts can be applied internally to all requests. I tested the order of execution using console.log, and the results were as follows:

  1. Request scripts for collections (Pre-request Script)
  2. Request scripts for folders (Pre-request Script)
  3. Request scripts for requests (Pre-request Script)
  4. Perform the requested
  5. Collection of test scripts (Tests Script)
  6. Test scripts for folders (Tests Script)
  7. Requested test script (Tests Script)

Back to requirements, after the request, environment variables are set dynamically, so you can do this in the Tests Script.

First we parse the response data, convert it into a JSON object, and then evaluate the return interface. If the request is ok, we set the environment variable via pm.environment.set. Also, you can add test points, which can be seen in the Tests Result of the response. In addition, there are many snippets on the right side of the interface to help beginners get started quickly.

Unset (“variable_key”) can be called in the test script to remove the interface to clear the environment variable, thus completing the loop.

3.2 Whole Process Test (Runner)

The interfacing problem is fixed, but it still requires the tester to click on it one by one, which is not smart enough.

Here, we use Postman’s Runner feature to automate the whole process of testing.

Before testing, it is a good idea to walk through the business process to identify problems.

After the process is sorted out, we can configure it.

In Ruuner interface, we can set the test environment and run times on the left side, and select the interface to be tested and adjust the call order on the right side. The order of calls can also be adjusted in the test script using pm.setNextrequest (“request_name”).

Click the Run button and wait for a moment to get a test result page. Since we set the test point before, according to the 0 FAILED in the upper left corner, we can know that the test result has passed.

At this point, automated integration testing is complete.

4 more

We’ve done all this with Postman’s visual interface, but Postman also has a command-line tool: Newman. With continuous integration tools such as Jenkins, automated testing can be truly realized.

The command line tool can be installed via NPM:

npm install -g newman
Copy the code

For details, see the official documents.

5 Reference Materials

  • Postman technical documentation