Postman Scripting & Automation
⚙️ Postman Scripting & Automation
Pre-Request Scripts
A pre-request script is JavaScript that runs before the request is sent — useful for computing something the request needs on the fly, like a current timestamp or a signature.
Test Scripts: pm.test()
A test script runs after the response arrives, and is where real assertions live — checking a status code, a header, or a specific field's value, using pm.test() blocks and Chai-style pm.expect() assertions.
Every test in the script runs automatically each time the request runs — no one has to remember to manually check anything, and Postman's runner shows a clear pass/fail per test.
Chapter 3's Manual Step vs. This Chapter's Automated One
Manual (Chapter 3)
A person selects the token in the response body and clicks "Set as variable" — has to remember to do it, every single time the login request runs.
Automated (This Chapter)
A test script does the exact same thing in code, every time, with no one needing to remember anything: pm.environment.set("authToken", pm.response.json().token);
| API | Purpose |
|---|---|
pm.response.to.have.status(code) | Assert the response status code |
pm.response.json() | Parse the response body as JSON |
pm.expect(value).to... | Chai-style assertion on any value |
pm.environment.set(name, value) | Store a value into the active environment |
pm.environment.get(name) | Read a value from the active environment |
Automating Chapter 3's Login Chain
The login request's Test script now does in one automatic step what Chapter 3 did by hand:
Every subsequent request in the collection referencing {{authToken}} automatically gets whatever this run just extracted — no manual click required, and it now fails loudly (a red test) if login itself ever stops returning a 200.
Newman: Running a Collection From the Command Line
Newman is Postman's official CLI runner — it executes an entire collection (with all its test scripts) with no Postman application open at all, printing a pass/fail summary and exiting with a non-zero code if anything failed.
This is the concrete bridge from "a Postman collection I click through" to "an automated regression suite" — the same collection built by hand in Chapters 2–3 can now run unattended, in a CI pipeline, on every commit.
Mock Servers
Postman can generate a mock server from a collection's saved example responses — a fake but realistic backend that returns those saved examples for matching requests. This lets a frontend team build and test against realistic API responses before the real backend exists, or lets a test suite run without depending on a real backend that might be slow, rate-limited, or still under construction.
💻 Coding Challenges
Challenge 1: Write a Test Script
Write a test script for a GET /products/42 request that asserts: the status is 200, and the response body's id field equals 42.
Goal: Practice writing two independent pm.test() blocks using pm.response.to.have.status() and pm.expect().
Challenge 2: Automate a Chained Variable
A "Create Order" request returns { "id": "O123", "status": "processing" }. Write the test script line that automatically saves id into an environment variable called orderId, the automated version of Chapter 3's manual chaining challenge.
Goal: Practice converting a manual "Set as variable" step into a one-line automated equivalent.
Challenge 3: Explain Newman's Role in CI
Explain what running newman run collection.json as a step in a CI pipeline actually verifies, and what a non-zero exit code should cause the pipeline to do.
Goal: Practice connecting Newman's exit code to CI/CD Pipelines course concepts (a failing test should fail the build, per pipelines1-4).
Newman exits with a non-zero code when any test fails — that's exactly what a CI pipeline is supposed to detect and fail on. But it's an easy mistake to wrap the command in a way that discards that signal, e.g. newman run collection.json || true, or piping its output through another command that doesn't propagate the original exit code. The pipeline then reports success even though real API tests just failed — silently defeating the entire point of running Newman in CI in the first place. This is the exact same discipline pipelines1-4 established for any test step: the build must fail when the tests do, with nothing in between quietly absorbing that failure.
🎯 What's Next
The next chapter steps outside Postman entirely: VS Code as a REST Client — the REST Client extension's version-controllable .http files, and Thunder Client as a Postman-like in-editor alternative.