Bird
Raised Fist0
Postmantesting~20 mins

Dynamic assertion values in Postman - Practice Problems & Coding Challenges

Choose your learning style10 modes available
Challenge - 5 Problems
🎖️
Dynamic Assertion Master
Get all challenges correct to earn this badge!
Test your skills under time pressure!
❓ assertion
intermediate
2:00remaining
Dynamic assertion with timestamp validation
You have a Postman test that checks if the response JSON contains a timestamp field that should be within the last 5 minutes. Which assertion correctly validates this dynamically?
Postman
const responseTime = new Date(pm.response.json().timestamp);
const now = new Date();
const diffMinutes = (now - responseTime) / 60000;
Apm.test('Timestamp is recent', () => { pm.expect(diffMinutes).to.be.at.least(5); });
Bpm.test('Timestamp is recent', () => { pm.expect(diffMinutes).to.be.below(5); });
Cpm.test('Timestamp is recent', () => { pm.expect(diffMinutes).to.equal(5); });
Dpm.test('Timestamp is recent', () => { pm.expect(diffMinutes).to.be.above(5); });
Attempts:
2 left
💡 Hint
Think about how to check if the timestamp is within the last 5 minutes, not older.
❓ Predict Output
intermediate
2:00remaining
Output of dynamic variable assertion in Postman
Given this Postman test code, what will be the test result if the response JSON is {"count": 10} and the environment variable 'expectedCount' is set to '10' (string)?
Postman
const actualCount = pm.response.json().count;
const expectedCount = pm.environment.get('expectedCount');
pm.test('Count matches expected', () => {
  pm.expect(actualCount).to.eql(Number(expectedCount));
});
ATest passes because pm.expect does type coercion automatically
BTest fails because actualCount is number but expectedCount is string
CTest fails with TypeError due to type mismatch
DTest passes because actualCount (10) equals Number(expectedCount) (10)
Attempts:
2 left
💡 Hint
Check how the expectedCount is converted before assertion.
🔧 Debug
advanced
2:00remaining
Debugging a failing dynamic assertion in Postman
This Postman test is supposed to check if the response header 'x-rate-limit-remaining' is greater than zero. However, it always fails. What is the cause?
Postman
const remaining = pm.response.headers.get('x-rate-limit-remaining');
pm.test('Rate limit remaining positive', () => {
  pm.expect(remaining).to.be.above(0);
});
Apm.expect cannot compare header values
BHeader name is incorrect; should be 'X-Rate-Limit-Remaining' with capitals
Cremaining is a string, so the numeric comparison fails; convert to number first
Dpm.response.headers.get returns an array, not a string
Attempts:
2 left
💡 Hint
Check the data type of the header value before comparing.
❓ framework
advanced
2:00remaining
Using dynamic variables in Postman pre-request scripts
You want to set a dynamic timestamp variable 'currentTime' in Postman before sending the request, so you can use it in assertions later. Which code correctly sets this environment variable?
Apm.environment.set('currentTime', new Date().toISOString());
Bpm.environment.get('currentTime', new Date().toISOString());
Cpm.variables.set('currentTime', new Date());
Dpm.environment.set('currentTime', Date.now);
Attempts:
2 left
💡 Hint
Remember how to set environment variables and the correct way to get current time as string.
🧠 Conceptual
expert
2:00remaining
Why use dynamic assertion values in API testing?
Which is the best reason to use dynamic assertion values in Postman tests instead of hardcoded values?
ATo ensure tests adapt to changing data and remain valid over time
BTo make tests run faster by avoiding fixed values
CTo reduce the number of tests needed by using random values
DTo avoid writing any assertions manually
Attempts:
2 left
💡 Hint
Think about test reliability when data changes.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard