Postman: collections, environments and test scripts

In this tutorial you will build a Postman collection for the Brew & Bean API: saved requests, an environment for the base URL, test scripts that check each response automatically, and a one-click run of the whole collection. At the end you will run the same collection from the terminal with Newman, which is how teams run it in CI.

Prerequisites: the practice API from the lesson *Testing APIs by hand* running at http://127.0.0.1:8000, and Postman (the desktop app is free to download; at the time of writing (2026) it has a free plan with some limits, and you may need to create a free account to use all features, so check postman.com for the current terms). If you prefer an open-source tool that works without an account, the next lesson does the same job in Bruno.

curl is great for one-off checks, but it gets painful when you have 30 requests, several environments (your laptop, a test server) and checks you want to repeat. An API client such as Postman gives you:

- Saved requests grouped in collections, so you do not retype anything. - Variables and environments, so the same request runs against local, staging and production by switching one dropdown. - Test scripts that pass or fail automatically. - A runner that executes the whole collection and shows a report.

Why an environment? Imagine the API moves to a test server at some other address. You change one value (baseUrl) instead of editing 30 requests. Environments are also where you keep secrets like API keys, never hard-coded in requests.

Variables are used with double curly braces: {{baseUrl}}. Postman replaces them when the request is sent.

Postman runs JavaScript after each response. Open the request's Scripts tab (in older versions it is called Tests) and choose Post-response. Paste this:

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

pm.test("Menu has 8 items", function () {
  const menu = pm.response.json();
  pm.expect(menu).to.be.an("array").with.lengthOf(8);
});

pm.test("Every item has an id, name and a positive price", function () {
  pm.response.json().forEach(function (item) {
    pm.expect(item).to.have.property("id");
    pm.expect(item).to.have.property("name");
    pm.expect(item.price).to.be.above(0);
  });
});

Three checks. pm.test names a check, and pm.expect uses the Chai assertion library that Postman includes.

Click Send again. In the response area open the Test Results tab. You should see three green PASS lines. To see a failure, change lengthOf(8) to lengthOf(9), send again and read the red FAIL message, then change it back.

Each pm.test is one named check. If the assertion inside throws, that check fails, and the others still run. Give checks names that say what should be true, so a failure explains itself.

Add a second request named Create order: method POST, URL {{baseUrl}}/orders. Open the Body tab, choose raw and JSON in the dropdown, and paste:

Now the post-response script. Besides checking the response, it stores the new order's id in a variable so the next request can use it. Chained requests like this are how you test a flow.

pm.test("Order is created", function () {
  pm.response.to.have.status(201);
});

const order = pm.response.json();

pm.test("Total is computed by the server", function () {
  pm.expect(order.total).to.eql(390);
});

pm.test("New order starts as received", function () {
  pm.expect(order.status).to.eql("received");
});

pm.test("Responds in under 500 ms", function () {
  pm.expect(pm.response.responseTime).to.be.below(500);
});

pm.environment.set("orderId", order.id);

Checks the response and saves order.id as the environment variable orderId.

Send it. Open the Local environment and you will see orderId now has a value such as ord-1001. Each run of the API creates a new id, which is why you save it instead of typing it.

Add Get order: GET {{baseUrl}}/orders/{{orderId}} with this script:

Add Move order to preparing: PATCH {{baseUrl}}/orders/{{orderId}}/status with a raw JSON body {"status": "preparing"} and the script:

Add two more requests that should fail. Their passing test is the failure: it proves the API protects itself.

Create order, bad phone: POST {{baseUrl}}/orders with the same body but "phone": "12345". Skip a status: PATCH {{baseUrl}}/orders/{{orderId}}/status with {"status": "picked_up"}.

pm.test("Skipping a status is refused with 409", function () {
  pm.response.to.have.status(409);
});

Run this one while the order is in preparing: moving straight to picked_up should be refused.

Because Create order runs before Get order, the saved orderId flows through. This is the big idea: a collection is a small automated test suite, not just a bookmark list.

Newman is Postman's command-line runner. It runs a collection without opening the app, so a CI server can do it. First export the collection (the three dots beside the collection, then Export) as brew-bean.postman_collection.json, and the environment (the three dots beside Local, then Export) as local.postman_environment.json. Then, with Node.js installed:

npm install -g newman
newman run brew-bean.postman_collection.json -e local.postman_environment.json

Runs every request and prints a summary table of requests, assertions and failures. The exit code is non-zero if any test fails, so CI can stop the build.

Write Postman post-response test scripts (JavaScript using pm.test and pm.expect) for the response below.

Request: [method and URL]
Expected behaviour: [what the API should do, including rules like value ranges]
Sample response:
[paste a real JSON response]

Include: a status check, checks on every field's type and value, a response-time check, and one check that would fail if the response shape changed. Use only the pm API.

What to expect: Read every generated assertion before using it. AI often invents field names or checks values that change each run (like ids and timestamps). Run the tests, then break the API on purpose to confirm they actually fail.