Postman: Advanced guide with environments, tests and mock servers

Posted by Isabel Arnaiz

If you already reviewed our previous article “Postman: a quick guide for beginners” and you know the basics of this tool —creating your account, structuring your first collections and running requests—, it’s time to level up. Here we will delve into more advanced aspects of Postman, such as creating environments, local variables, more complete tests, mock servers and team collaboration.

Create environments for a server

In the previous post we described how to create workspaces and configure environment variables in a basic way. Now, we will explore the use of environments in more depth to manage different configurations (for example, URLs, credentials, etc.) without needing to manually change the requests.

In Postman, click on New and then select Environment.
Assign a name to your environment (for example, Entorno_Swapi if you are going to test the Star Wars API).
Add the variables you need. One of the most common ones is the base URL of your API. For SWAPI it could be:

Variable: host
Initial Value: https://swapi.dev/api/
Current Value: https://swapi.dev/api/

Every time you create or edit your environment, save it and select it in the top right corner of the Postman window so that your requests use those variables.

Collections and requests with environment variables

A collection lets you save a set of requests. Collections can be saved in different folders to keep them more organized. To create a collection, you need to provide a name and optionally a description.

Create a collection using the New → Collection button. Assign it a name and, if you want, a description.

Now it’s time to create the requests. This is where the real action happens. We can create a request from various places in Postman. For example, from the three dots of our collection, choosing “Add Request.”

Once the Request is created, we need to give it a name and place it in a collection. To better organize the code, it is possible to create folders within collections. In the example, we have created a folder called StarshipsFolder and inside it we have created the request StarshipsRequest:

With that, the request looks like this:

In this example, we are trying to get a list of spaceships, so in the screenshot you can see:

The request name.
API: The full address would be swapi.co/api/starships, but since we already saved swapi.co/api in the environment variable host, we only need to type {{host}} to use it.
Environment.
Method: It can be GET, POST, PUT, DELETE…

Test automation in Postman

You have probably seen in the previous publication that from the Tests tab you can write JavaScript code to validate the responses of your requests. However, in this section we will take it a step further, showing more complete examples:

Basic tests

For example, a simple test to validate that the HTTP response is 200 could look like this:

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

Tests with custom checks

In an API like SWAPI, you may want to check how many results you get from the request. Imagine you expect 100 spaceships:

var results = pm.response.json().results;

pm.test("More than 100 starships", function () {
    pm.expect(results).to.have.lengthOf(100);
});

If the API returns fewer than 100, the test will fail. You can see it in the Postman Test Console or by using the Collection Runner.

Save and run

The next step would be to save the request by clicking the “Save” button and choosing where to save it. We can save it in the collection itself or in the folder we created earlier. Then, we can run it by clicking on “Run.”

Once run, we see that out of the two tests, the second one failed because it expected 100 responses and only received 10.

Once we have created the desired tests within the collection, it is possible to run them all together using the “Collection Runner.” To access it, select the triangle next to the collection and click Run:

A menu will open that allows us to configure how we want to run the requests in the collection. Once here, we must indicate:

Choose between running the entire collection or just one folder.
Choose the environment where we have stored the variables.
The number of times we want to run the tests.
Run Collection (Start Test)

Once the execution finishes, you can see the results on the right side of the screen. At the very top there is a summary that shows how many tests failed, how many passed, and how long they took to run. Below that, the same is shown, but for each request made:

Test expansion

In the same request, let’s create a third test that will consist of a loop to store in an environment variable called “falcon” information about a specific ship among all those returned, searching for “Millennium Falcon.”

The code will be as follows:

pm.environment.set("falcon",results.filter(x => x.name === "Millennium Falcon"));

var myStarship = pm.environment.get("falcon");


pm.test("One item only", function () {

        pm.expect(myStarship).to.have.lengthOf(1);

        console.log(myStarship);

});

TRY:

Number of ships of the “Starfighter” class.
Number of ships with a crew larger than the population of Viladecans.

Local variables of a collection

In addition to being able to declare variables within the server environment, it is possible to declare local variables for use in a specific collection. To do this, we go to the desired collection and click on the Variables option:

Once there, we can add the variables we need in the presented table, which is divided into three columns:

Variable → In this column we write the name we want the new variable to have.
Initial Value → This column is used to declare the created variable with a value, and so that this value is visible if the collection is shared with other users.
Current Value → Unlike Initial Value, this column is used to declare the variable with a value that will not be shared if the collection is shared with other users.

Below is an example of creating the variable port:

Once we have created our variable, to use it in different requests we must call it using {{variable_name}}:

Create a Mock Server

In many cases, development teams need a set of APIs to be available before they are actually running. This often happens because in most projects, the Frontend development team is different from the Backend team, and they may have different development speeds. To resolve this type of situation, you can create a Mock Server.

A Mock Server consists of creating a series of requests in which we have programmed the output we want them to have. To use this feature in Postman, we must first be logged into the program.

The steps to follow are:

Make the request we want to mock and save it within a collection.
In the request, select the three dots to open the More Actions menu. Then, you need to click Add example, and a file will be created within the request.
In the new file, you must write inside the body, in JSON format, the desired output we want the request to return.
Next, right-click on the collection where the request is and select Mock Collection.
Enter the details to configure the server.
Copy the new URL and go back to our request, where we will replace the base URL with the generated one.
Make the call and Postman should return the response given in the Add example body.

Invite collaborators

If your project involves multiple testers or developers, Postman allows all of you to work collaboratively in the same workspace:

Click the Invite button in the top right corner of your workspace.
Add the emails or names of the people you want to give access to. You can even import a .txt or .csv file with multiple contacts.
Determine whether they will have editing permissions or just viewing permissions.

In a matter of seconds, your team can share collections, environments, and mock servers, centralizing all the work in one place.

With these features, your Postman experience gains a greater level of automation and organization. If you still have questions about the initial configuration of Postman, the creation of your first workspaces, or the basic sending of requests, remember that in "Postman: a quick guide for beginners" you have a step-by-step introduction.

Happy testing! And if you need more specialized help to integrate your API tests into development pipelines or to optimize your QA strategy, do not hesitate to contact us.