Postman collections, environments and test scripts

Sending one request in Postman is a demo. A tester's job is a collection that runs in order, pulls a token from the login response, uses it in the next request, and reports pass or fail for every check. Screenings for API roles often ask you to build exactly this. Here is the structure and the scripts.

Collections and environments

A collection is a folder of requests saved with their headers, bodies and tests. Group requests by resource (Auth, Users, Orders) and order them so dependencies run first. An environment is a set of variables such as baseUrl, token and userId. Reference them as {{baseUrl}}/orders. Keep one environment per target (dev, staging) with the same variable names, so switching targets is one dropdown. Store secrets as secret-type variables and never commit a filled environment file to a shared repository.

Test scripts

The Tests tab runs JavaScript after the response arrives:

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

pm.test("Response time under 800 ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(800);
});

const body = pm.response.json();

pm.test("Order has an id and the right total", function () {
    pm.expect(body.id).to.be.a("number");
    pm.expect(body.total).to.eql(49.98);
    pm.expect(body.items).to.have.lengthOf(2);
});

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

The last line saves the new id so the next request can call {{baseUrl}}/orders/{{orderId}}. For the login request, do the same with the token: pm.environment.set("token", pm.response.json().access_token), and set the Authorization header on the collection to Bearer {{token}} so every request inherits it. The Pre-request tab runs before sending; use it to generate a unique email such as pm.variables.set("email", "qa+" + Date.now() + "@example.com") so repeated runs do not fail on duplicates.

Running the whole thing

The Collection Runner executes every request in order and shows a pass or fail count. For CI, export the collection and environment and run them with Newman:

newman run orders.postman_collection.json -e staging.postman_environment.json --reporters cli,junit --reporter-junit-export results.xml

A failing test gives a non-zero exit code, which fails the pipeline step. Worked example: a nightly job runs the collection against staging; a developer changes the price field from a number to a string; the to.be.a("number") check fails before anyone opens the app.

Common mistakes and a practice habit

• Hard-coding the base URL in every request, then editing fifty requests when staging moves.
• Only checking the status code. A 200 with an empty body passes that test and hides the bug.
• Tests that depend on data created by hand yesterday. Create what you need in the collection.
• Saving a token in a global variable shared across environments.

Practice habit. Pick any free public API. Build a collection of five requests with a login or key step, chain one id between requests, add three assertions to each, and run it with Newman from the command line. Break one assertion on purpose to see the failure output.