🔥 Writing Automated Tests

Writing Automated Tests: Postman test scripts work exactly like a quality control gate at the end of a factory conveyor belt — every product (API response) passes through an auto

Postman test scripts work exactly like a quality control gate at the end of a factory conveyor belt — every product (API response) passes through an automated inspection before it is allowed to leave the line. The inspector does not just look at the label (status code 200); it measures dimensions (response time under 500ms), checks the materials list (JSON schema), verifies the serial number is not null (id field), and confirms the product is not a duplicate (unique token). Now the real question: if you are already writing JUnit assertions in Java to test business logic, why write JavaScript assertions in Postman too? Because Postman tests are executed at the HTTP boundary, not inside the JVM — they prove that the API contract as experienced by any external consumer is correct, independent of the implementation language. In CI terms, a failing Postman test in Newman is a broken API contract: the kind of silent regression that causes a mobile app or a third-party integration to receive wrong data formats, empty arrays where items were expected, or 200 status codes masking a failed transaction — exactly the bugs that unit tests never catch because they never cross the network.

The pm.test() API — Writing Assertions

The Tests tab runs JavaScript after every request. The pm (Postman) object provides all assertion tools. Results appear in the "Test Results" tab in the response panel — with green ✅ or red ❌ per test.

Tests Tab — Core Assertions:

Why Does the Difference Between pm.test() and pm.expect() Matter?

pm.test("name", fn) DEFINES a test BLOCK…

`pm.test("name", fn)` DEFINES a test BLOCK and gives it the name that will APPEAR in the Test Results panel — similar to writing `@Test public void testX()` in Java.

pm.expect(...) is the actual assertion…

`pm.expect(...)` is the Chai assertion that does the actual checking INSIDE that block — a `pm.expect` without `pm.test` still runs but WON'T appear as a SEPARATE row in Test Results.

Five separate pm.test() blocks for one…

Writing 5 separate `pm.test()` blocks for one response means even if one FAILS, the other 4 keep RUNNING — a DIFFERENT behavior from a classic try/catch where one break STOPS everything.

Java QA engineers use REST Assured for API testing. Postman uses the same BDD-style assertion concepts — just JavaScript (Chai library) instead of Java.

Both use given/when/then style. pm.test() names the test; pm.expect() is the assertion. Chai assertion library is built into Postman.

Chaining Requests — Passing Data Between Requests