Why Write Test Scripts?
Test scripts live in the Tests tab and run after Postman receives a response, giving you a place to programmatically verify the API behaved correctly. Each check is wrapped in a pm.test('description', function) block, and inside it you use Chai-style pm.expect() assertions; every block's pass or fail status shows individually in the Test Results panel, so a single request can carry many independent checks.
Cricket analogy: Like the third umpire reviewing a run-out only after the throw and stumping happen, checking the outcome against replay evidence rather than predicting it beforehand.
Writing Assertions with pm.expect()
A typical test script combines several assertions: confirming the HTTP status code with pm.response.to.have.status(200), checking pm.response.responseTime is below a threshold, and parsing the body with pm.response.json() to assert specific fields exist and hold the expected values. Because each assertion is chained through pm.expect(), you get readable failure messages that point straight at which check broke.
Cricket analogy: Hawk-Eye validates line, pitch, and impact together on a single LBW appeal — checking three related facts at once, the way a test script checks status, timing, and body together.
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
pm.test("Response time is less than 500ms", function () {
pm.expect(pm.response.responseTime).to.be.below(500);
});
const jsonData = pm.response.json();
pm.test("Response has an 'id' field", function () {
pm.expect(jsonData).to.have.property('id');
});
pm.test("Order total matches request", function () {
const requestBody = JSON.parse(pm.request.body.raw);
pm.expect(jsonData.total).to.eql(requestBody.total);
});Test results from every request in a Collection Runner or Newman run are aggregated into a single pass/fail summary, which is exactly the signal a CI pipeline (e.g. a GitHub Actions step running newman run collection.json) checks to gate a deploy.
Common Assertion Patterns
Beyond simple field checks, seasoned test scripts validate response shape (using jsonSchema assertions), array lengths, and header presence, often splitting related checks into separate pm.test blocks so a single failure doesn't obscure the others. It's usually better to write several small, clearly named tests than one giant test with many unrelated assertions bundled together.
Cricket analogy: Like checking both the scoreboard total and the required run rate together during a chase — two separate but related checks needed to judge the true state of the match.
An uncaught exception thrown inside a single pm.test() callback only fails that one test — other pm.test blocks still execute. But a syntax error or thrown exception outside of any pm.test wrapper, at the top level of the Tests tab, can abort the entire script, so wrap risky logic inside pm.test blocks.
- The Tests tab contains JavaScript that runs after the response is received.
- pm.test('name', function) wraps a single named assertion; failures show individually in the Test Results panel.
- pm.expect() provides Chai-style assertions such as .to.equal, .to.be.below, and .to.have.property.
- pm.response gives access to status, response time, headers, and body via pm.response.json().
- Test results roll up across Collection Runner and Newman runs, which is how CI pipelines gate on API behavior.
- An error thrown inside one pm.test block fails only that test; other pm.test blocks still run independently.
Practice what you learned
1. In which tab do you write assertions that run after a Postman response arrives?
2. What does pm.test() take as arguments?
3. Which of these correctly checks that the response status code is 200?
4. If one pm.test block throws an error, what happens to other pm.test blocks in the same Tests tab?
5. How do you access the parsed JSON body of a response inside a test script?
Was this page helpful?
You May Also Like
Pre-request Scripts
How to run JavaScript before a Postman request is sent, to set variables, compute signatures, and build dynamic request data.
Chaining Requests with Extracted Data
How to pass data from one Postman request's response into the next request by extracting values in a test script and storing them as variables.
The pm API: Request, Response, and Environment
A tour of Postman's core pm object — pm.request, pm.response, and pm.environment — the JavaScript API used in both pre-request and test scripts.
Dynamic Variables and Faker Data
How to use Postman's built-in dynamic variables like {{$guid}} and {{$randomEmail}} to generate realistic fake data on every request.