Dynamic assertion values in Postman - Framework Patterns

Framework Mode - Dynamic assertion values

Folder Structure for Postman Test Automation

PostmanCollection/
├── collections/
│   └── api-collection.json          # Main API collection with requests
├── environments/
│   ├── dev.postman_environment.json # Dev environment variables
│   ├── qa.postman_environment.json  # QA environment variables
│   └── prod.postman_environment.json # Production environment variables
├── tests/
│   ├── dynamic_assertions.js        # Scripts for dynamic assertions
│   └── utils.js                     # Helper functions for assertions
├── reports/
│   └── test-report.html             # Generated test reports
└── postman.config.json              # Configuration for Newman CLI runs

Test Framework Layers in Postman

• Collection Layer: Contains API requests grouped logically. Each request can have pre-request and test scripts.
• Environment Layer: Holds environment-specific variables like base URLs, tokens, or dynamic data placeholders.
• Test Scripts Layer: JavaScript code inside requests or separate files that perform dynamic assertions using variables and response data.
• Utilities Layer: Helper functions for common tasks like parsing JSON, generating dynamic values, or comparing timestamps.
• Configuration Layer: Settings for running tests via Newman or Postman CLI, including environment selection and report output.

Configuration Patterns for Dynamic Assertions

• Environment Variables: Store dynamic values like tokens, timestamps, or IDs to reuse across requests and assertions.
• Global Variables: Use for values shared across collections or environments, such as common user IDs.
• Pre-request Scripts: Generate or update dynamic values before sending requests (e.g., current timestamp).
• Test Scripts: Extract response data and set variables dynamically for assertions in subsequent requests.
• Newman CLI Configuration: Use --env-var or --global-var flags to override variables at runtime for flexible test runs.

Test Reporting and CI/CD Integration

• Newman Reports: Generate HTML, JSON, or JUnit reports from Postman collections run via Newman CLI.
• CI/CD Pipelines: Integrate Newman runs in pipelines (GitHub Actions, Jenkins, GitLab CI) to automate tests on code changes.
• Dynamic Assertion Logs: Use console.log() in test scripts to output dynamic values and assertion results for debugging.
• Failure Alerts: Configure pipeline notifications (email, Slack) on test failures to quickly address issues.

Best Practices for Dynamic Assertion Values in Postman

1. Use Environment Variables: Avoid hardcoding values; store dynamic data in environment variables for easy updates.
2. Chain Requests with Variables: Extract values from one response and use them in subsequent requests and assertions.
3. Write Clear Assertions: Use descriptive messages in pm.test() to clarify what is being checked dynamically.
4. Modularize Helper Functions: Keep reusable assertion logic in utility scripts to reduce duplication.
5. Validate Data Types: When asserting dynamic values, check both value and type to avoid false positives.

Self Check Question

Where in this folder structure would you add a new helper function to parse and validate dynamic timestamps used in assertions?

Key Result

Use environment variables and test scripts to handle dynamic assertion values in Postman collections.

Practice

1. What is the main purpose of using dynamic assertion values in Postman tests?

easy

A. To make tests flexible by comparing values that change each time

B. To hardcode fixed values for all test runs

C. To disable assertions temporarily

D. To speed up test execution by skipping checks

Solution

1. Step 1: Understand dynamic assertion values

   Dynamic assertion values allow tests to compare values that can change between API calls, making tests adaptable.

2. Step 2: Identify the purpose in Postman

   Using dynamic values helps verify API responses that return different data each time, ensuring tests remain valid.

3. Final Answer:

   To make tests flexible by comparing values that change each time -> Option A

4. Quick Check:

   Dynamic assertions = flexible tests [OK]

Hint: Dynamic values adapt tests to changing data [OK]

Common Mistakes:

• Thinking dynamic means disabling assertions
• Confusing dynamic with fixed values
• Assuming dynamic values speed up tests

2. Which of the following is the correct way to use a Postman variable in an assertion to check a response value dynamically?

easy

A. pm.expect(pm.response.json().data.id).to.eql('{{$randomId}}');

B. pm.expect(pm.response.json().data.id).to.eql(pm.variables.get('randomId'));

C. pm.expect(pm.response.json().data.id).to.eql('$randomId');

D. pm.expect(pm.response.json().data.id).to.eql(randomId);

Solution

1. Step 1: Recall Postman variable syntax in scripts

   In test scripts, variables are accessed using pm.variables.get('variableName').

2. Step 2: Identify correct assertion usage

   pm.expect(pm.response.json().data.id).to.eql(pm.variables.get('randomId')); correctly uses pm.variables.get('randomId') to get the variable value for comparison.

3. Final Answer:

   pm.expect(pm.response.json().data.id).to.eql(pm.variables.get('randomId')); -> Option B

4. Quick Check:

   Use pm.variables.get() for dynamic values [OK]

Hint: Use pm.variables.get('name') to access variables in tests [OK]

Common Mistakes:

• Using {{}} inside test scripts instead of pm.variables.get()
• Using variable name as plain string without get()
• Assuming $variable syntax works in scripts

3. Given this Postman test snippet:

pm.test('Check user ID', () => {
  const expectedId = pm.variables.get('userId');
  pm.expect(pm.response.json().id).to.eql(expectedId);
});

If the variable userId is set to 123 and the response JSON is {"id": 124}, what will be the test result?

medium

A. Test passes because values are close

B. Test throws syntax error

C. Test fails because 124 != 123

D. Test is skipped due to missing variable

Solution

1. Step 1: Compare expected and actual values

   The expected value from variable userId is 123, but response JSON has id 124.

2. Step 2: Evaluate assertion outcome

   The assertion to.eql(123) vs actual 124 will fail because they are not equal.

3. Final Answer:

   Test fails because 124 != 123 -> Option C

4. Quick Check:

   Mismatch values cause test failure [OK]

Hint: Check exact values in assertions to predict pass/fail [OK]

Common Mistakes:

• Assuming close numbers pass equality
• Confusing syntax error with assertion failure
• Ignoring variable value in test

4. You wrote this Postman test:

pm.test('Check token', () => {
  const token = pm.variables.get('authToken');
  pm.expect(pm.response.json().token).to.eql(token);
});

But the test always fails even though the token looks correct. What is the most likely cause?

medium

A. The variable authToken is not set or is empty

B. The response JSON does not contain a token field

C. The assertion syntax is invalid

D. Postman does not support dynamic assertions

Solution

1. Step 1: Check variable usage

   If authToken is missing or empty, pm.variables.get('authToken') returns undefined or empty string.

2. Step 2: Understand assertion failure

   Comparing response token to undefined or empty string causes assertion to fail even if response token is correct.

3. Final Answer:

   The variable authToken is not set or is empty -> Option A

4. Quick Check:

   Unset variables cause assertion mismatches [OK]

Hint: Always verify variables are set before assertions [OK]

Common Mistakes:

• Assuming syntax error without checking variables
• Ignoring missing response fields
• Believing Postman lacks dynamic assertion support

5. You want to test an API that returns a new order ID each time. You store the previous order ID in a variable prevOrderId. Which Postman test code correctly asserts that the new order ID is different from the previous one?

hard

A. pm.expect(pm.response.json().orderId).to.eql(pm.variables.get('prevOrderId'));

B. pm.expect(pm.response.json().orderId).to.be.lessThan(pm.variables.get('prevOrderId'));

C. pm.expect(pm.response.json().orderId).to.be.greaterThan(pm.variables.get('prevOrderId'));

D. pm.expect(pm.response.json().orderId).not.eql(pm.variables.get('prevOrderId'));

Solution

1. Step 1: Understand the requirement

   The test should confirm the new order ID is different from the previous one, so equality must fail.

2. Step 2: Choose correct assertion

   pm.expect(pm.response.json().orderId).not.eql(pm.variables.get('prevOrderId')); uses not.eql to assert the new ID is not equal to the previous ID, matching the requirement.

3. Final Answer:

   pm.expect(pm.response.json().orderId).not.eql(pm.variables.get('prevOrderId')); -> Option D

4. Quick Check:

   Use not.eql to assert values differ [OK]

Hint: Use not.eql to check values are different [OK]

Common Mistakes:

• Using eql to check difference (wrong)
• Assuming greaterThan always works for IDs
• Confusing lessThan with difference check