Automation with Postman Collection Runners

A lot of us probably use Postman in our daily development work. For those who are not aware of it, Postman is a tool used to test API calls. The norm is for development team to create a “Collection” of HTTP requests (i.e. a group of different endpoints). These requests are normally in sequential order and manually executed to achieve the expected outcome. For example:

Figure 1: Collection with 5 requests

In Figure 1, each of these requests normally save values obtained in their responses to be used in subsequent requests.

Despite many of us using Postman, some might not be aware of its additional functionality that we could utilise to speed up testing. This functionality is called “Collection Runner” (Figure 2). “Collection Runner” at its default settings enables different requests to be run sequentially at a click of a button without having to click on each request.

Figure 2: Collection Runner

Additionally, “Collection Runner” could be used with data files (CSV or JSON). This ability is very useful to those who are not very familiar with Postman (e.g. Product Owners, Business Analysts etc.) as they could alter for example the content of data files, number of iterations and delay between requests without having to worry about Postman’s technicalities.

On top of that, there is one other valuable functionality that many people are not aware of which is the ability for Postman to choose specific request to be executed next. This will be elucidated later on.

In this blog, I will demonstrate how the above functionalities were used to achieve the goal that will be described below.

Goal

The goal is to select and add different items into a shopping cart. The process should be executed on Postman by a click of a button utilising data file in JSON format.

Problems

Requests for both ‘Select flowers’ and ‘Select bread’ (Figure 1) have different total number of key/value pairs in their JSON payloads.

Solution

Firstly, the different requests were listed and their flow was designed accordingly, in this case:

• Login as user
• Select flowers
• Select bread
• Go to cart
• Logout

The flow was as the following:

Flow 1: Login as user->Select flowers->Go to cart->Logout
Flow 2: Login as user->Select bread  ->Go to cart->Logout

Data file content in JSON format:

{
       “item”:”Flowers”,
       “selectItemRequest”: “Select flowers"
},
{
       “item”:”Bread”,
       “selectItemRequest”: “Select bread”
}
             Figure 3: Data file in JSON format

In order to achieve the desired outcome, some variables were programmatically stored as environment variables which would be used in subsequent requests, e.g.:

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable(“sessionToken”, jsonData.sessionToken);
         
      Figure 4: sessionToken stored as environment variable

In the above JSON (Figure 3), “selectItemRequest” key/value pair was used by “Login as a user” request in its “Pre-request Script” (Figure 5) to determine which request that needed to be executed next.

For example, when “Collection Runner” was run with “Iterations” set to 2 (Figure 2); during the first iteration, Postman would read the first block of the JSON file (Figure 3) by internally assigning key “selectItemRequest” to value “Select flowers”. This value was then used in the “Pre-request Script” (Figure 5) stage of the “Login as a user” request utilising “postman.setNextRequest” method which called the next request with title “Select flowers” (Figure 1). Later on, requests to “Go to cart” and “Logout” were also made by taking advantage of “postman.setNextRequest” method. However, for the final two requests, as we did not require any data from the JSON file, it was sufficient to just hard code the calls in their previous requests, e.g. in “Select flowers” “Pre-request Script”:

postman.setNextRequest("Go to cart");

Figure 5: Pre-request script showing setNextRequest method

After “Logout” request had been executed, the iteration proceeded to the second iteration by reading the second block (Figure 3) of the JSON file and internally assigning key “selectItemRequest” to value “Select bread”. The same process occured as during the first iteration.

Conclusion

It was possible to create an end to end automation test via Postman that did not have to follow sequential order as displayed in its “Collection”.

The ability to use data file in Postman was beneficial as end users could modify data if needed.

Knowing how to automatically re-use values from API responses was hugely beneficial when coupled with “Collection Runner” since it enabled API automation testing to happen with little manual intervention.