Dynamic assertion values in Postman - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to assert the response status is 200.

Postman

pm.test("Status code is 200", function () {
    pm.response.to.have.status([1]);
});

Drag options to blanks, or click blank then click option'

A201

B200

C404

D500

Attempts:

3 left

💡 Hint

Common Mistakes

Using a wrong status code like 201 or 404.

Forgetting to put the status code as a number.

The status code 200 means the request was successful. We use pm.response.to.have.status(200) to check this.

2fill in blank

medium

Complete the code to assert the JSON response has a property 'userId' equal to 1.

Postman

pm.test("User ID is 1", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.[1]).to.eql(1);
});

Drag options to blanks, or click blank then click option'

Aid

Buserid

Cuser_id

DuserId

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect property names like 'id' or 'userid'.

Not matching the case exactly.

The JSON response property is named userId. We access it as jsonData.userId to check its value.

3fill in blank

hard

Fix the error in the code to assert the response time is less than 500 ms.

Postman

pm.test("Response time is less than 500ms", function () {
    pm.expect(pm.response.[1]).to.be.below(500);
});

Drag options to blanks, or click blank then click option'

AresponseTime

Btime

Cduration

Delapsed

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect property names like 'time' or 'duration'.

Confusing response time with other response properties.

The correct property for response time in Postman is pm.response.responseTime. Using this allows the assertion to check the response time correctly.

4fill in blank

hard

Fill both blanks to assert the JSON response array length is greater than 3.

Postman

pm.test("Array length is greater than 3", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.[1].[2]).to.be.above(3);
});

Drag options to blanks, or click blank then click option'

Aitems

Blength

Ccount

Dsize

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong property names like 'count' or 'size'.

Trying to check length on a non-array property.

The JSON response has an array property named items. To get its length, we use items.length. Then we check if it is above 3.

5fill in blank

hard

Fill all three blanks to assert the response header 'Content-Type' includes 'json'.

Postman

pm.test("Content-Type header includes json", function () {
    var contentType = pm.response.headers.get('[1]');
    pm.expect(contentType.[2]('[3]')).to.be.true;
});

Drag options to blanks, or click blank then click option'

AContent-Type

Bincludes

Cjson

Dcontent-type

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong header name like 'content-type' (wrong case).

Using wrong string method like 'contains' instead of 'includes'.

Checking for wrong substring.

We get the header named Content-Type (case sensitive). Then we check if it includes the string json using the includes method.

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