Postman basics for the little ones

In this article, I will talk about the basics of working with Postman for novice testers. I myself came across this tool just on the last project.

I’ll tell you how to use it to create the simplest autotests and reduce the amount of routine using variables.

Let’s start with a few words about what Postman is. It is an API tool that allows a tester to send requests to services and work with their responses. With its help, you can test the backend and make sure that it works correctly.

There are many tools with similar functionality. I chose Postman because it is the most popular. But it has other benefits as well. Postman:

• intuitive and easy to use, does not require any complex setup or knowledge of programming languages;

• free, so a team of any size can work in it;

• supports various APIs (REST, SOAP, GraphQL);

• expandable for any needs using the Postman API;

• easily integrates into CI / CD using Newman, a console utility for running tests;

• runs on any OS;

• supports manual and automated testing;

• gathered a large community around him, where you can find answers to any questions.

This tool allows the tester to:

• send requests and receive responses;

• save requests to folders and collections;

• change query parameters;

• change environments (dev, test, production);

• perform autotests using Collections runner, including on a schedule;

• Import and export collections of queries and test suites to communicate with colleagues.

Let’s get to the point.

On our project, we are developing an advertising campaign manager. Each campaign in our system has a number of fields – name, description, ID, and creative (ads that the user sees). To demonstrate the capabilities of Postman, I will use requests to create and update a campaign and a creative from a “combat” project.

Experimenting with an update request

Let’s create the simplest campaign update request.

If it is successful, we will receive a 200 OK response.

Let’s write the simplest autotest that will check this. To do this, in the Postman interface, go to the Tests tab. The code from this tab will be executed after receiving a response to the request.

You don’t have to write code from scratch. Postman has a ready-made list of API validation tests. Any of them can be edited to suit your needs to save time.

Ready scripts (snippets) are in the list on the right. There you can find code to check all or part of the response, the request execution time, and a lot of other things.

We select the snippet, it is added to the Tests tab. This code can be edited to provide a different test name or answer.

pm.test(“Status code is 200”, function () {
	pm.response.to.have.status(200);
});

We save the code and send the request.

The result can be found in the Test Results tab. We see:

Let’s check that the test actually works. Change the response code to 400.

pm.test(“Status code is 200”, function () {
	pm.response.to.have.status(200);
});

Let’s save the query and run the test again.

Quite expectedly, the test falls, because the real answer is 200 OK:

Similarly, you can check that the response body contains a specific string. In our case, let’s see if there is the name of the advertising campaign, which we passed in the request to update the data.

We are looking for the corresponding snippet and edit it for our task:

pm.test(“Body matches string”, function () {
	pm.expect(pm.response.text()).to.include(“Campaign TEST”);
});

We save and send the request. We see that the test was successful.

As in the previous example, we can check the performance of the test by correcting the sought line:

pm.test(“Body matches string”, function () {
	pm.expect(pm.response.text()).to.include(“Campaign TEST1”);
});

You can search for a string not in the entire body of the response, but in a specific field. To check that the campaign name is exactly in the Name field, let’s edit another snippet:

pm.test(“Your test name”, function () {
	var jsonData = pm.response.json();
pm.expect(jsonData.name).to.eql(“Campaign TEST”);
});

Multiple tests can be created for one request. For example, like this:

pm.test(“Status code is 200”, function () {
	pm.response.to.have.status(200);
});

pm.test(“Body matches string”, function () {
	pm.expect(pm.response.text()).to.include(“Campaign TEST”);
});

pm.test(“Campaign status check”, function () {
	var jsonData = pm.response.json();
pm.expect(jsonData.status).to.eql(“Draft”);
});

Here we check the status code, the content in the response body of the campaign name and the fact that after the update the campaign status is “Draft”.

In the Test Results tab, we will see that all three tests completed successfully:

Running autotests with Collection runner

The collection runner does not run individual tests, but their collections.

A new collection can be created using the + icon on the Collections tab (in each such collection, you can create a folder with tests using Add Folder).

If you create multiple collections, it will look something like this:

To run the Collection runner, you need to select a collection and click Run on the tab that opens. The requests will be executed one at a time. After the completion of the execution, you can see all the results:

For each request, you can see detailed data in the drop-down menu – which URL the request was sent to, what data is in the header, etc.

Similarly, you can view the body and header of the response. But for this you need to enable logging (enable the Save response checkbox before starting the collection).

When the collection starts, the Collection runner allows you to set the number of iterations. This is very convenient, especially when there are a lot of requests – the tests do not have to be run manually.

Postman also knows how to run collections on a schedule. Click on the collection name, open the Action menu and set the schedule on the Monitor collection tab.

Variables in Postman

It is convenient to use variables during testing.

Let’s say we recently cleaned up the database and for testing we need to fill it in – create several advertising campaigns with different names. In order not to do it manually, you can use dynamic random variables.

There are many random variables in Postman. If you start typing paired curly braces while writing code, Postman will tell you which ones are available.

You can read more about variables in Postman documentation…

Let’s select $ randomInt for our test. Let’s save and send the request.

It succeeds, the campaign gets a random name.

Instead of $ randomInt, you can choose, say, a random month – $ randomMonth.

To get unique data, you can also insert variables in the header and URL in the same way.

Scopes

Postman supports several kinds of variables, depending on the space and scope. The idea is well illustrated by a picture from the documentation:

The following types of variables are supported:

• Global – variables that do not belong to any environment, they are available in the entire workspace, from all environments. Global variables can be used to pass data between collections, queries, and environments.

• Collection variables are available in all queries within the same collection.

• Environment variables change depending on the selected environment.

• Local variables are temporary. They are available only within the request and are used when you need to rewrite collection variables or some kind of global values.

• Data variables are file variables. I will dwell on them in detail later.

Global variables cannot have duplicates. But local variables can have the same names, but only if they are in different environments. If Postman encounters two variables with the same name, the local variable takes precedence (it will overwrite the global one).

Environment variables

Let’s talk about environment variables. They allow you to pass data from request to request within this environment.

Let’s create an environment before starting our experiments. To do this, select Environments in the left menu and click either the plus sign or Create a new environment. On the tab that opens, you can set the name of the environment. Let it be Environment token.

A great example of using environment variables is passing an authorization token. If the token expires, then the test fails with an error 401. In all the requests that I sent before, I received and inserted fresh authorization tokens manually (behind the scenes of my story). When there are only a few requests, it is not difficult. But when there are a lot of requests, it is easier to implement this through an environment variable. To do this, we will set a variable and assign an appropriate value to it, and then use the variable in all requests.

Let’s set the varBearerToken variable in the Environment token environment. Let’s substitute our token as the initial value. It remains to replace the token value with a variable in the request header.

As with random variables, you can start typing double curly braces. Since Postman knows this variable (in the given environment), it will prompt the value.

If we remove Environment, Postman will no longer offer hints, since the variable is not available outside of its environment. No environment – no environment variables.

Likewise, you can fulfill our requests at different stands. In order not to manually change the URL in each request, you can register a stand-alternate. Let it be varStage with default test.

Similarly, you could register dev and other stands.

It remains to add this variable to the URL. As with the token, Postman will highlight it only if the environment in which it is specified is selected.

The environment with all the variables can be shared with colleagues by exporting to a json file. They will be able to open it at their workplace in Postman.

Passing data between requests

A very important feature for writing tests is passing values ​​from request to request using environment variables.

In the previous example, I created an environment variable varToken and manually assigned a token to it. But instead of copying, the token can be obtained in the response to the authorization request and passed it to other requests.

Let’s create a new environment Environment Auth. We will not prescribe any variables at the start. Let’s just select this environment and take the corresponding script from the list of snippets. We will declare the varToken variable right in it and assign the token value to it (for this we parse the JSON response):

var jsonData = JSON.parse(responseBody);
pm.environment.set(“varToken”, jsonData.data.token);

console.log(jsonData);
console.log(jsonData.data.token);

For clarity, I added more output of variables to the console to see their values.

We clean the console, run it. And we see the result – the jsonData variable and the token value that we assign to varToken.

It remains to register the varToken variable in the Header of our campaign creation requests.

Since we work inside the Environment Auth environment, Postman knows about it.

Now let’s complicate the example. Let’s say we want to create an ad campaign, find out its ID, and then update the campaign with that ID.

Let’s declare another variable – varID. To do this, we set the name of the variable in the script, in the same place we assign it a value from the response to the request:

var jsonData = JSON.parse(responseBody);
pm.environment.set(“varID”, jsonData.id);

console.log(jsonData);
console.log(jsonData.data.id);

We launch the Collection runner and see that the requests are working.

We got the token, passed it to all subsequent requests, got the campaign ID and passed it to the update request. After that we updated it.

By the way, in the environment that we created, all these variables will be specified, along with the current values:

Using Postman’s capabilities, campaign updates can be performed on a scheduled basis.

Data variables

The Collection runner can use data variables.

To demonstrate how this works, let’s create several advertising campaigns with parameters specified through a file. Let’s say we don’t want random values ​​and need strictly defined campaign names to test sorting or filtering.

Create a file with the csv or json extension. Postman supports both types of files, the only question is in the format.

In the csv file, the first line contains the name of a variable or several variables separated by commas. Further on separate lines are values ​​(or several values ​​separated by commas).

In the json file, you can write the same thing, but in the JSON key-value format.

To add variables to the Collection runner, you need to click the Select File button and load any of these files. The Collection runner will automatically count the number of values ​​(and therefore test iterations). There you can also see the names and values ​​of variables by clicking on the Preview Data button.

If we run the Collection runner and then check the campaign names, we will see that the values ​​from the files are used.

Hope you found this helpful. Postman has many features that can help even beginners with testing.

The author of the article: Natalia Shilova.

PS We publish our articles on several sites on the Runet. Subscribe to our pages in VK, FB, Instagram or Telegram channelto stay informed about all our publications and other Maxilect news.