Interview Corner

A: Both check the status code, but pm.response.to.have.status(200) is a shorthand from Postman's BDD assertion library — it reads naturally and gives a clear error message. pm.expect(pm.response.code).to.eql(200) is the Chai-style approach — more verbose but flexible. The Chai approach lets you do things like .to.be.oneOf([200, 201]) or .to.be.within(200, 299), which the shorthand cannot. I use the shorthand for exact checks and pm.expect for range checks.

A: I create a login/auth request as the first request in my collection. Its Post-response script extracts the token from the response and saves it using pm.environment.set("authToken", token). All subsequent requests reference {{authToken}} in their Authorization header. When I run the collection, login executes first and populates the token for all other requests. For OAuth2, I use Postman's built-in authorization tab. For API keys, I set them as environment variables.

A: pm.environment.set() stores variables in the currently active environment — they're scoped to that environment and can have different values in dev, staging, and production. pm.globals.set() stores variables globally — accessible from any environment and any collection. I prefer environment variables because they're more organized and prevent accidental cross-environment leaks. Global variables are useful for things like API keys that stay the same across all environments.

A: I use the Collection Runner with a CSV or JSON data file. The CSV has columns matching variable names — like email, password, expectedStatus. In the request, I reference these as {{email}} and {{password}}. In the test script, I use pm.iterationData.get("expectedStatus") to check the expected outcome. Each row in the file becomes one iteration. This lets me test 100 different inputs without creating 100 separate requests.

A: Postman uses the Chai assertion library with the BDD expect syntax. Unlike plain JavaScript if-else or console.log checks, Chai provides readable assertion chains like pm.expect(value).to.be.a("string").and.not.be.empty. Each assertion gives a descriptive error message on failure — "expected 42 to be a string" — which makes debugging easy. Chai supports deep equality (eql), type checking (be.a), property checking (have.property), and many more. Regular JavaScript would require manual error message handling.

A: I validate schema in two ways. First, manually — by checking that all required fields exist using pm.expect(response).to.have.all.keys() and verifying types with pm.expect(field).to.be.a("string"). Second, using JSON Schema validation with tv4 library (built into Postman): I define a JSON schema object and use tv4.validate(response, schema) to check the entire structure at once. The manual approach is simpler for small APIs. JSON Schema is better for complex nested structures with many fields.

A: Pre-request scripts run before the HTTP request is sent. Real-world example: our e-commerce API requires a unique order ID in every create-order request. In the pre-request script, I generate one using Date.now() and store it with pm.environment.set("orderId", "ORD-" + Date.now()). The request body uses {{orderId}}. Another example: generating HMAC signatures for secure APIs — the pre-request script computes the signature from the request body and current timestamp, then sets it as a header variable.

A: I export the Postman collection and environment as JSON files. Then I use Newman — Postman's command-line runner — to execute them in CI/CD. The command is: newman run collection.json -e environment.json --reporters cli,htmlextra. Newman supports all Postman test features — assertions, variables, chaining. I integrate it into Jenkins/GitHub Actions as a post-deployment step. If any test fails, the pipeline fails and the team gets notified. This is covered in detail in the Newman chapter.