Bird
Raised Fist0
Postmantesting~8 mins

Response body assertions 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 - Response body assertions
Folder Structure
PostmanCollectionProject/
├── collections/
│   └── api_tests.postman_collection.json
├── environments/
│   ├── dev.postman_environment.json
│   ├── staging.postman_environment.json
│   └── prod.postman_environment.json
├── tests/
│   └── responseBodyAssertions.test.js
├── scripts/
│   └── utils.js
├── reports/
│   └── test-report.html
└── postman.config.json
Test Framework Layers
  • Collections: Store API requests grouped by functionality.
  • Environments: Define variables like base URLs and credentials for different setups.
  • Tests: JavaScript files with test scripts that include response body assertions.
  • Scripts/Utilities: Helper functions for common validation tasks.
  • Reports: Generated test execution reports showing pass/fail results.
  • Configuration: Settings for running tests, environment selection, and reporting.
Configuration Patterns
  • Environment Files: Use separate JSON files for dev, staging, and prod to manage URLs and tokens.
  • Global Variables: Store reusable data like auth tokens or user IDs.
  • Collection Variables: Variables scoped to the collection for test-specific data.
  • Config File: postman.config.json to define default environment and report settings.
  • Dynamic Environment Switching: Use CLI tools like Newman with environment flags to run tests against different setups.
Test Reporting and CI/CD Integration
  • Newman CLI: Run Postman collections from command line with detailed JSON or HTML reports.
  • Reporters: Use built-in reporters like HTML, JSON, or JUnit for CI tools.
  • CI/CD Pipelines: Integrate Newman commands in pipelines (GitHub Actions, Jenkins, GitLab CI) to run tests on code changes.
  • Fail Fast: Configure tests to stop on first failure or continue to gather full results.
  • Notifications: Send test results via email or chat on pipeline completion.
Best Practices
  • Clear Assertions: Write simple, readable assertions checking exact response body values or JSON paths.
  • Use Schema Validation: Validate response structure with JSON schema to catch unexpected changes.
  • Isolate Tests: Each test should verify one aspect of the response body to simplify debugging.
  • Reusable Scripts: Put common assertion logic in utility scripts to avoid duplication.
  • Environment Safety: Never hardcode sensitive data; use environment variables instead.
Self Check

Where in this framework structure would you add a new assertion script to verify that the response body contains a specific user ID?

Key Result
Organize Postman API tests with collections, environment configs, reusable scripts, and clear response body assertions for reliable validation.

Practice

(1/5)
1. What does pm.response.json() do in Postman tests?
easy
A. It parses the response body as a JSON object.
B. It sends a new request to the server.
C. It clears the response body.
D. It validates the response status code.

Solution

  1. Step 1: Understand the purpose of pm.response.json()

    This function reads the response body and converts it into a JSON object for easy access.
  2. Step 2: Compare with other options

    Sending requests, clearing body, or validating status are different functions, not pm.response.json().
  3. Final Answer:

    It parses the response body as a JSON object. -> Option A
  4. Quick Check:

    Parsing response body = A [OK]
Hint: Remember: json() reads response body as JSON [OK]
Common Mistakes:
  • Confusing json() with sending requests
  • Thinking json() clears data
  • Mixing response body parsing with status code checks
2. Which of the following is the correct syntax to assert that the response JSON has a key status with value success in Postman?
easy
A. pm.expect(response.status).to.equal('success');
B. pm.response.json().status == 'success';
C. pm.expect(pm.response.json().status).to.eql('success');
D. pm.assert(pm.response.status == 'success');

Solution

  1. Step 1: Identify correct assertion syntax in Postman

    Postman uses pm.expect() with Chai assertion style, so pm.expect(pm.response.json().status).to.eql('success'); is correct.
  2. Step 2: Check other options for errors

    pm.response.json().status == 'success'; lacks assertion, C uses wrong object, D uses incorrect method.
  3. Final Answer:

    pm.expect(pm.response.json().status).to.eql('success'); -> Option C
  4. Quick Check:

    Use pm.expect() with to.eql() for value check [OK]
Hint: Use pm.expect() with to.eql() for JSON value checks [OK]
Common Mistakes:
  • Using == instead of pm.expect() for assertions
  • Referencing response.status instead of response.json().status
  • Using pm.assert() which is not a Postman function
3. Given this response body:
{"user":{"id":5,"name":"Alice"}}
What will this test output?
const jsonData = pm.response.json();
pm.test("User ID is 5", () => {
  pm.expect(jsonData.user.id).to.equal(5);
});
medium
A. Test passes because user.id equals 5.
B. Test fails because user.id is not 5.
C. Test throws an error due to syntax.
D. Test is skipped because no assertion is made.

Solution

  1. Step 1: Parse the response JSON

    The response has user.id = 5, so jsonData.user.id is 5.
  2. Step 2: Evaluate the assertion

    The test asserts jsonData.user.id equals 5, which is true, so the test passes.
  3. Final Answer:

    Test passes because user.id equals 5. -> Option A
  4. Quick Check:

    Value matches assertion = Pass [OK]
Hint: Match JSON path value with expected to pass test [OK]
Common Mistakes:
  • Misreading JSON structure
  • Assuming test fails without checking value
  • Confusing syntax errors with assertion failures
4. Identify the error in this Postman test code:
const data = pm.response.json();
pm.test("Check user name", () => {
  pm.expect(data.user.name).to.equal('Bob')
});
medium
A. Missing semicolon after assertion line.
B. No error; the test code is correct.
C. Incorrect function name; should be pm.test, not pm.tests.
D. Missing parentheses after pm.expect.

Solution

  1. Step 1: Review syntax of Postman test code

    The code uses pm.test correctly, with proper arrow function and assertion syntax.
  2. Step 2: Check for syntax errors

    Semicolons are optional in JavaScript; parentheses and function names are correct.
  3. Final Answer:

    No error; the test code is correct. -> Option B
  4. Quick Check:

    Correct syntax means no error [OK]
Hint: Check function names and parentheses carefully [OK]
Common Mistakes:
  • Confusing pm.test with pm.tests
  • Thinking semicolons are mandatory
  • Missing parentheses in pm.expect
5. You want to assert that the response JSON array items contains an object with id equal to 10. Which test code correctly checks this in Postman?
hard
A. pm.expect(pm.response.json().items.id).to.equal(10);
B. const items = pm.response.json().items; pm.expect(items.find(id => id === 10)).to.exist;
C. pm.expect(pm.response.json().items.includes({id:10})).to.be.true;
D. const items = pm.response.json().items; pm.expect(items.some(item => item.id === 10)).to.be.true;

Solution

  1. Step 1: Understand the response structure

    items is an array of objects; we want to check if any object has id 10.
  2. Step 2: Evaluate each option

    const items = pm.response.json().items; pm.expect(items.some(item => item.id === 10)).to.be.true; uses some() to check if any item has id === 10, which is correct. pm.expect(pm.response.json().items.id).to.equal(10); wrongly accesses items.id (invalid). pm.expect(pm.response.json().items.includes({id:10})).to.be.true; tries to use includes() with an object, which won't work. const items = pm.response.json().items; pm.expect(items.find(id => id === 10)).to.exist; uses find() but the callback is incorrect (should check item.id).
  3. Final Answer:

    const items = pm.response.json().items; pm.expect(items.some(item => item.id === 10)).to.be.true; -> Option D
  4. Quick Check:

    Use some() with correct callback for array check [OK]
Hint: Use some() to check if array contains object with property [OK]
Common Mistakes:
  • Using includes() with objects (doesn't work)
  • Accessing array properties directly
  • Incorrect callback function in find()