Bird
Raised Fist0
Postmantesting~8 mins

Status code assertion in Postman - Framework Patterns

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Framework Mode - Status code assertion
Folder Structure
PostmanCollectionProject/
├── collections/
│   └── UserAPI.postman_collection.json
├── environments/
│   ├── dev.postman_environment.json
│   ├── staging.postman_environment.json
│   └── prod.postman_environment.json
├── tests/
│   └── status_code_assertion.test.js
├── scripts/
│   └── pre-request-scripts.js
├── reports/
│   └── test-report.html
└── postman.config.json
Test Framework Layers
  • Collections: Group of API requests organized by feature or service.
  • Environments: Variables for different deployment stages (dev, staging, prod).
  • Tests: JavaScript files or inline scripts in Postman to assert response status codes and data.
  • Scripts: Pre-request or setup scripts to prepare data or headers before requests.
  • Reports: Generated test reports showing pass/fail results of assertions.
  • Config: Configuration file to manage global settings like base URLs and authentication tokens.
Configuration Patterns
  • Environment Variables: Use environment files to store base URLs, API keys, and tokens for each environment.
  • Global Variables: For values shared across all environments, like common headers.
  • Collection Variables: Scoped to the collection for reusable data like user IDs.
  • Pre-request Scripts: Dynamically set or update variables before sending requests.
  • Config File: postman.config.json to define default environment and report settings.
Test Reporting and CI/CD Integration
  • Newman CLI: Run Postman collections from command line with detailed reports.
  • Report Formats: Generate HTML, JSON, or JUnit XML reports for CI tools.
  • CI/CD Pipelines: Integrate Newman runs in Jenkins, GitHub Actions, GitLab CI to automate tests on code changes.
  • Fail Fast: Configure pipelines to stop on failed status code assertions to prevent faulty deployments.
  • Notifications: Send test results via email or chat tools on test completion.
Best Practices
  • Assert Exact Status Codes: Always check for the precise expected status code (e.g., 200, 404) to catch errors early.
  • Use Environment Variables: Avoid hardcoding URLs or tokens; use variables for flexibility.
  • Keep Tests Simple: One assertion per test script for clarity and easier debugging.
  • Organize Collections: Group related API requests logically for maintainability.
  • Automate Reporting: Use Newman with CI to get consistent, automated feedback on API health.
Self Check

Where in this folder structure would you add a new test script to verify the status code for a new API endpoint?

Answer: Add the test script inside the tests/ folder, for example as new_endpoint_status_code.test.js.
Key Result
Use Postman collections with environment variables and Newman CLI for automated status code assertions and reporting.

Practice

(1/5)
1. What does the status code 200 usually mean in a Postman response?
easy
A. The request was successful
B. The server could not find the requested resource
C. There was a server error
D. The request was unauthorized

Solution

  1. Step 1: Understand HTTP status codes

    Status code 200 means the request was processed successfully by the server.
  2. Step 2: Match code to meaning

    200 is the standard code for success, unlike 404 (not found) or 500 (server error).
  3. Final Answer:

    The request was successful -> Option A
  4. Quick Check:

    Status 200 = Success [OK]
Hint: 200 means success, always check for it first [OK]
Common Mistakes:
  • Confusing 200 with error codes like 404 or 500
  • Thinking 200 means unauthorized access
  • Assuming 200 means redirect
2. Which of the following is the correct syntax to assert a status code of 404 in a Postman test script?
easy
A. pm.response.assert.status(404);
B. pm.response.to.have.status(404);
C. pm.response.status(404);
D. pm.test.status(404);

Solution

  1. Step 1: Recall Postman assertion syntax

    The correct way to check status code is using pm.response.to.have.status(code).
  2. Step 2: Verify each option

    Only pm.response.to.have.status(404); matches the correct syntax exactly.
  3. Final Answer:

    pm.response.to.have.status(404); -> Option B
  4. Quick Check:

    Use pm.response.to.have.status() [OK]
Hint: Use pm.response.to.have.status(code) for status checks [OK]
Common Mistakes:
  • Omitting 'to.have' in the assertion
  • Using pm.response.status() which is invalid
  • Trying pm.test.status() which does not exist
3. Given this Postman test code:
pm.test('Check status', () => {
  pm.response.to.have.status(201);
});

What will be the test result if the server responds with status code 200?
medium
A. Test will pass
B. Test will be skipped
C. Test will error out
D. Test will fail

Solution

  1. Step 1: Understand the assertion

    The test expects status code 201 (Created) exactly.
  2. Step 2: Compare actual response code

    The server returned 200 (OK), which does not match 201, so assertion fails.
  3. Final Answer:

    Test will fail -> Option D
  4. Quick Check:

    Expected 201 but got 200 = Fail [OK]
Hint: Exact status code must match to pass assertion [OK]
Common Mistakes:
  • Assuming 200 and 201 are interchangeable
  • Thinking test errors instead of fails
  • Believing test skips on mismatch
4. You wrote this Postman test:
pm.test('Status is 200', () => {
  pm.response.to.have.status = 200;
});

What is wrong with this test?
medium
A. Status code 200 is invalid
B. Missing semicolon at the end
C. Incorrect use of assignment instead of function call
D. pm.test syntax is wrong

Solution

  1. Step 1: Check assertion syntax

    The code uses = which assigns a value instead of calling status(200) as a function.
  2. Step 2: Identify correct usage

    The correct syntax is pm.response.to.have.status(200); to assert status code.
  3. Final Answer:

    Incorrect use of assignment instead of function call -> Option C
  4. Quick Check:

    Use parentheses for function calls, not assignment [OK]
Hint: Use parentheses () to call status function, not = [OK]
Common Mistakes:
  • Using = instead of calling status()
  • Ignoring syntax errors thinking test runs
  • Confusing semicolon importance
5. You want to write a Postman test that passes only if the response status code is either 200 or 201. Which code snippet correctly asserts this?
hard
A. pm.test('Status is 200 or 201', () => { pm.expect(pm.response.code === 200 || pm.response.code === 201).to.be.true; });
B. pm.test('Status is 200 or 201', () => { pm.response.to.have.status(200 || 201); });
C. pm.test('Status is 200 or 201', () => { pm.response.to.have.status(200) || pm.response.to.have.status(201); });
D. pm.test('Status is 200 or 201', () => { pm.response.to.have.status([200, 201]); });

Solution

  1. Step 1: Understand how to check multiple status codes

    Postman does not support passing multiple codes directly to status().
  2. Step 2: Use logical OR with pm.expect

    pm.test('Status is 200 or 201', () => { pm.expect(pm.response.code === 200 || pm.response.code === 201).to.be.true; }); uses pm.expect with a boolean expression checking if code is 200 or 201, which is correct.
  3. Final Answer:

    pm.test('Status is 200 or 201', () => { pm.expect(pm.response.code === 200 || pm.response.code === 201).to.be.true; }); -> Option A
  4. Quick Check:

    Use pm.expect with OR condition for multiple codes [OK]
Hint: Use pm.expect with OR to check multiple status codes [OK]
Common Mistakes:
  • Passing multiple codes directly to status()
  • Using logical OR outside pm.expect
  • Assuming status() accepts arrays