Status codes reading in Postman - Framework Patterns

Framework Mode - Status codes reading

Folder Structure

PostmanCollectionProject/
├── collections/
│   └── api-tests.postman_collection.json
├── environments/
│   ├── dev.postman_environment.json
│   ├── staging.postman_environment.json
│   └── prod.postman_environment.json
├── tests/
│   └── statusCodeTests.postman_test.js
├── scripts/
│   └── utils.js
├── reports/
│   └── test-report.html
└── README.md

This structure organizes Postman collections, environment files, test scripts, utility scripts, and reports clearly.

Test Framework Layers

• Collections: Contains API requests grouped logically. Each request includes tests for status codes.
• Environments: Holds environment-specific variables like base URLs and credentials.
• Tests: JavaScript files with reusable test functions, e.g., checking status codes.
• Scripts: Utility functions to support tests, such as logging or common assertions.
• Reports: Generated test run reports showing pass/fail results for status code checks.

Configuration Patterns

• Environment Files: Use separate JSON files for dev, staging, and prod to manage URLs and tokens.
• Global Variables: Store common values like API keys in environment variables for easy updates.
• Collection Variables: Use for request-specific data that may change per collection run.
• Pre-request Scripts: Dynamically set or update variables before requests run.
• Postman CLI (Newman) Config: Use command-line options to specify environment and collection files for automation.

Test Reporting and CI/CD Integration

• Newman Reports: Generate HTML or JSON reports after running collections via Newman CLI.
• CI/CD Integration: Integrate Newman runs into pipelines (Jenkins, GitHub Actions) to automate tests on code changes.
• Fail Fast: Configure tests to stop on critical status code failures to save time.
• Notifications: Send test results via email or messaging tools when status code tests fail.

Best Practices

• Explicit Status Code Checks: Always assert expected status codes (e.g., 200, 404) clearly in tests.
• Reusable Test Functions: Create helper functions to check status codes to avoid repetition.
• Use Environment Variables: Avoid hardcoding URLs or tokens; use environment variables for flexibility.
• Clear Test Naming: Name tests descriptively to indicate which status code is being verified.
• Separate Concerns: Keep test logic separate from request definitions for easier maintenance.

Self Check

Where would you add a new test script that verifies the API returns a 401 Unauthorized status code when no token is provided?

Key Result

Organize Postman API tests with collections, environments, reusable test scripts, and integrate reporting for clear status code validation.

Practice

1. What does the status code 200 usually mean in Postman response testing?

easy

A. The request was successful and the server returned the expected data.

B. The requested resource was not found on the server.

C. The server encountered an internal error.

D. The client is not authorized to access the resource.

Solution

1. Step 1: Understand HTTP status codes

   Status code 200 means OK, indicating success in HTTP responses.

2. Step 2: Interpret 200 in Postman context

   In Postman, a 200 status means the request succeeded and data was returned.

3. Final Answer:

   The request was successful and the server returned the expected data. -> Option A

4. Quick Check:

   Status code 200 = Success [OK]

Hint: 200 means success, like a green light [OK]

Common Mistakes:

• Confusing 200 with error codes like 404 or 500
• Thinking 200 means unauthorized access
• Assuming 200 means no data returned

2. Which of the following is the correct way to check for a 404 status code in a Postman test script?

easy

A. pm.test('Status is 404', () => pm.response.code === 404);"

B. pm.test('Status is 404', () => pm.response.code == 404);

C. pm.test('Status is 404', () => pm.response.code === 404);

D. pm.test('Status is 404', () => pm.response.code = 404);

Solution

1. Step 1: Understand Postman test syntax

   Postman tests use pm.test with a callback function containing an assertion.

2. Step 2: Use correct assertion method

   While pm.expect(pm.response.code).to.eql(404) is preferred, the direct comparison requires strict ===, proper arrow function syntax, and no extra characters or assignment operators.

3. Final Answer:

   pm.test('Status is 404', () => pm.response.code === 404); -> Option C

4. Quick Check:

   Use triple equals and arrow function in pm.test [OK]

Hint: Use arrow function and triple equals for status check [OK]

Common Mistakes:

• Using single equals (=) instead of comparison
• Missing arrow function syntax
• Using double quotes inconsistently

3. Given this Postman test script:

pm.test('Check status', () => {
  pm.expect(pm.response.code).to.be.oneOf([200, 201]);
});

What will happen if the response status code is 201?

medium

A. The test will fail because 201 is not in the list.

B. The test will be skipped automatically.

C. The test will throw a syntax error.

D. The test will pass because 201 is included in the allowed codes.

Solution

1. Step 1: Understand the oneOf assertion

   pm.expect(...).to.be.oneOf([200, 201]) passes if the response code matches any value in the array.

2. Step 2: Check if 201 is in the array

   201 is included in [200, 201], so the assertion passes.

3. Final Answer:

   The test will pass because 201 is included in the allowed codes. -> Option D

4. Quick Check:

   201 in [200, 201] = pass [OK]

Hint: oneOf passes if code matches any listed status [OK]

Common Mistakes:

• Thinking 201 is not allowed
• Confusing oneOf with equals
• Assuming syntax error from array

4. You wrote this Postman test:

pm.test('Status is 200', () => {
  pm.expect(pm.response.code = 200);
});

Why does this test always pass even if the response code is not 200?

medium

A. Because the single equals sign assigns 200 instead of comparing, so assertion is always true.

B. Because pm.response.code is read-only and cannot be changed.

C. Because Postman ignores the test function if syntax is wrong.

D. Because the test is missing a semicolon.

Solution

1. Step 1: Identify the use of single equals in assertion

   The code uses pm.response.code = 200, which is assignment, not comparison.

2. Step 2: Understand effect of assignment in assertion

   Assignment returns 200 (truthy), so pm.expect always receives a truthy value, making the test pass regardless of actual status.

3. Final Answer:

   Because the single equals sign assigns 200 instead of comparing, so assertion is always true. -> Option A

4. Quick Check:

   Use '===' for comparison, not '=' [OK]

Hint: Use triple equals (===) for comparison, not single equals (=) [OK]

Common Mistakes:

• Confusing assignment (=) with comparison (===)
• Ignoring that assignment returns a truthy value
• Assuming syntax error instead of logic error

5. You want to write a Postman test that passes only if the response status code is between 200 and 299 inclusive. Which code snippet correctly implements this?

hard

A. pm.test('Status is 2xx', () => pm.expect(pm.response.code).to.equal(2));

B. pm.test('Status is 2xx', () => pm.expect(pm.response.code).to.be.within(200, 299));

C. pm.test('Status is 2xx', () => pm.expect(pm.response.code >= 200 && pm.response.code <= 299));

D. pm.test('Status is 2xx', () => pm.expect(pm.response.code).to.be.oneOf([200, 201, 202, 203, 204, 205]));

Solution

1. Step 1: Identify the correct assertion for range check

   pm.expect(...).to.be.within(min, max) checks if value is between min and max inclusive.

2. Step 2: Evaluate each option

   pm.test('Status is 2xx', () => pm.expect(pm.response.code).to.be.within(200, 299)); uses .within(200, 299) correctly. pm.test('Status is 2xx', () => pm.expect(pm.response.code).to.be.oneOf([200, 201, 202, 203, 204, 205])); lists only some codes, incomplete for full 2xx range. pm.test('Status is 2xx', () => pm.expect(pm.response.code >= 200 && pm.response.code <= 299)); uses invalid syntax inside pm.expect. pm.test('Status is 2xx', () => pm.expect(pm.response.code).to.equal(2)); checks for exact 2, which is wrong.

3. Final Answer:

   pm.test('Status is 2xx', () => pm.expect(pm.response.code).to.be.within(200, 299)); -> Option B

4. Quick Check:

   Use .within(200, 299) for range checks [OK]

Hint: Use .within(200, 299) to check 2xx status codes [OK]

Common Mistakes:

• Listing all codes instead of using range
• Using invalid boolean inside pm.expect
• Checking for exact number 2 instead of range