Postman basics

This article will be about the Postman basics for beginner testers. I’ll tell you how to create the simplest autotests and reduce the amount of routine using variables.

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

There are many tools with similar functionality. I chose Postman because it’s the most popular. But it also has other benefits. Postman:

• intuitive and easy to use, does not require any complex configuration or knowledge of programming languages;
• free;
• supports different APIs (REST, SOAP, GraphQL);
• expandable for any needs using the Postman API;
• easily integrated 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 request parameters;
• change environments (dev, test, production);
• run autotests using Collections runner, including scheduled ones;
• import and export query collections and test suites to share data with colleagues.

Let’s get to the point.

On our project, we are developing an advertising campaign manager. Each campaign in our system has several fields — name, description, ID, and creative (the user’s ad). To demonstrate the capabilities of Postman, I will use requests to create and update a campaign and ads content from the actual project.

Experimenting with the update request

Let’s create the most straightforward request to update the campaign.

The simplest request to update the campaign

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 a response.

The code does not have to be written from scratch. Postman has a ready-made list of tests for testing the API. Any of them can be edited to suit your needs to save time.

Ready-made scripts (snippets) are in the list on the right. There you can find code for checking the entire response or part of it, the request execution time, and many other things.

List of pre-made scripts on the right

Select the snippet, it is added to the Tests tab. This code can be edited — set 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 on the Test Results tab. We see:

The result of the test execution

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);
});

Save the query and rerun the test.

Quite expectedly, the test fails because the proper response is 200 OK:

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

Let’s take the appropriate snippet and edit it for our task:

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

Save and send the request. We see that the test was completed successfully.

As in the previous example, we can check if the test works by correcting the string we are looking for:

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 response body, but in a specific field. To check that the campaign name is present 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”);
});

You can create multiple tests for one query. For example:

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 of the campaign name in the response body, and the fact that after the update, the campaign status is “Draft.”

On the Test Results tab, we can see that all three tests have been completed successfully:

Running Autotests with Collection runner

Collection runner does not run individual tests but collections of them.

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 several collections, it will look something like this:

To start the Collection runner, you need to select a collection and click Run on the tab that opens. Requests will be executed sequentially. After the completion of the execution, you can see all the results:

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

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

The Collection runner allows you to set the number of iterations when running a collection. 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’s 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 purposes, we need to fill it in — create several advertising campaigns with different names. To avoid doing this manually, you can use dynamic random variables.

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

You can read more about variables in documentation for Postman.

For our test, we’ll choose $randomInt. Save and submit your request.

It is executed successfully. The campaign gets a random name.

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

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

Scopes

Postman supports several kinds of variables, depending on scopes and scopes. A picture from the documentation illustrates the idea:

Variable scopes in Postman

The following types of variables are supported:

• Global variables 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 inside the request and are used when you need to rewrite collection variables or some global values.
• Data variables are file variables. I will write about them later.

Global variables can’t have duplicates. But local variables can have the same names, but only in different environments. If Postman encounters two variables with the same name, the local variable will have the highest priority (it will override the global one).

Environment Variables

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

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

A great example of environment variables usage is passing an authorization token. If the token expires, then the test fails with a 401 error. In all the requests 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’s easier to implement this through an environment variable. To do this, we will define a variable, assign it the appropriate value, and then use the variable in all queries.

Set the varBearerToken variable in the Environment token environment. Let’s substitute our token as the initial value. It remains to replace the token’s 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 this environment), it will suggest the value.

If we remove the Environment, Postman will no longer offer hints since the variable is unavailable outside its environment. No environment means no environment variables.

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

Similarly, it would be possible to register dev and other stands.

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

Colleagues can rummage the environment with all variables through export to a JSON file. They will be able to open it at their workplace in Postman.

Passing Data Between Requests

An essential feature for writing tests is passing values ​​from request to request using environment variables.

I created the “varToken” environment variable in the previous example and manually assigned the token to it. But instead of copying the token, you can get it in response to the authorization request and pass it to other requests.

Let’s create a new environment, “Environment Auth.” We will not prescribe any variables at the start. Let’s select this environment and take the corresponding script from the list of snippets. Let’s declare the “varToken” variable directly in it and assign the value of the token to it (to do this, 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 also added the output of variables to the console to see their values.

We clean the console, we start, and we see the result — the jsonData variable and the value of the token, which we assign to “varToken”.

It remains to register the varToken variable in our requests to create a campaign in the Header.

Since we are working 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 one more variable — varID. To do this, we set the name of the variable in the script, in the same place we assign it the 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 started the Collection runner and saw 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.

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

Using Postman’s capabilities, campaign updates can be scheduled.

Data Variables

You can use data variables in the Collection runner.

Let’s create several advertising campaigns with parameters set via a file to demonstrate how this works. Suppose we don’t like random values ​​and need well-defined campaign names to test sorting or filtering.

We create a file with the extension CSV or JSON. Postman supports both file types. It’s just a matter of format.

The first line contains the name of a variable or several variables in the CSV file, separated by commas.

You can write the same thing in the JSON file in the JSON key-value format.

To add variables to the Collection runner, you need to click the Select File button and upload any of these files. Collection runner will automatically count the number of values ​​(and test iterations accordingly). You can also view the names and values ​​of variables there by clicking 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.

I hope you find it useful. Postman has many features that can help even beginners with testing.

Author of the article: Natalia Shilova.