Reusable test scripts in Postman - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Postman test script?

Consider this Postman test script that uses a reusable function to check response status:

function checkStatus(expected) {
    pm.test(`Status is ${expected}`, function () {
        pm.response.to.have.status(expected);
    });
}

checkStatus(200);

What will be the test result if the response status is 404?

Postman

function checkStatus(expected) {
    pm.test(`Status is ${expected}`, function () {
        pm.response.to.have.status(expected);
    });
}

checkStatus(200);

A Test fails with syntax error in function definition

B Test fails with message 'Status is 200' because actual status is 404

C Test passes because function runs without error

D Test passes because 404 is treated as 200 internally

💡 Hint

Think about what happens when the expected status does not match the actual response status.

The test checks if the response status equals 200. Since the actual status is 404, the assertion fails, causing the test to fail with the message 'Status is 200'.

❓ assertion

intermediate

Which assertion correctly reuses a variable for checking JSON response property?

You want to reuse the variable userId in multiple assertions in Postman tests. Which option correctly asserts that the response JSON has userId equal to 5?

Postman

const userId = 5;
pm.test('User ID is correct', () => {
    // assertion here
});

A pm.expect(pm.response.json().userId).to.eql('userId');

B pm.expect(pm.response.json().userId).to.eql(5);

C pm.expect(pm.response.json().userId).to.eql(userId.toString());

D pm.expect(pm.response.json().userId).to.eql(userId);

💡 Hint

Remember to use the variable name without quotes to refer to its value.

Option D correctly uses the variable userId to compare the JSON property. Option D compares to the string 'userId', which is incorrect. Option D hardcodes 5, which is not reusing the variable. Option D compares to string '5', which may fail if the JSON property is a number.

🔧 Debug

advanced

Why does this reusable test script fail to run in Postman?

Look at this reusable test script snippet intended to check response time:

function checkResponseTime(maxTime) {
    pm.test('Response time is acceptable', () => {
        pm.expect(pm.response.responseTime).to.be.below(maxTime);
    });
}

checkResponseTime(200);

When running, the test always passes even if response time is above 200ms. Why?

Postman

function checkResponseTime(maxTime) {
    pm.test('Response time is acceptable', () => {
        pm.expect(pm.response.responseTime).to.be.below(maxTime);
    });
}

checkResponseTime(200);

A pm.response.responseTime is in milliseconds, but the test expects seconds

B The function is not called properly, so test is skipped

C pm.response.responseTime is in seconds, but maxTime is in milliseconds

D pm.response.responseTime is undefined, so assertion always passes

💡 Hint

Check the units of pm.response.responseTime and the argument maxTime.

Postman reports pm.response.responseTime in milliseconds. If maxTime is given in seconds (e.g., 200 means 200 seconds), the test will always pass because responseTime is much smaller. The mismatch in units causes the logic error.

❓ framework

advanced

How to best organize reusable test scripts in Postman collections?

You want to reuse test scripts across multiple requests in a Postman collection. Which approach is best practice?

A Write reusable functions in the collection <code>Tests</code> tab and call them in each request test script

B Copy and paste the same test code into each request's <code>Tests</code> tab

C Use environment variables to store test scripts as strings and eval them in each request

D Write reusable test scripts only in the pre-request scripts

💡 Hint

Think about maintainability and avoiding duplication.

Option A is best practice: defining reusable functions in the collection Tests tab allows all requests in the collection to call them, promoting reuse and easier maintenance. Copy-pasting duplicates code. Using environment variables with eval is error-prone and insecure. Pre-request scripts run before requests, not suitable for test assertions.

🧠 Conceptual

expert

What is the main advantage of using reusable test scripts in Postman?

Choose the best explanation for why reusable test scripts improve API testing in Postman.

A They guarantee 100% test coverage without writing additional tests

B They allow tests to run faster by caching previous results automatically

C They reduce code duplication, making tests easier to maintain and update consistently

D They enable running tests without any network connection

💡 Hint

Think about maintainability and efficiency in test writing.

Reusable test scripts help reduce repeated code, so when you update a test logic, you do it once and all tests benefit. This improves maintainability and consistency. They do not affect test speed, offline capability, or guarantee coverage.

Practice

1. What is the main benefit of using reusable test scripts in Postman?

easy

A. They save time and reduce errors by avoiding repeated code.

B. They make the tests run slower but more secure.

C. They require writing the same code multiple times.

D. They only work with GET requests.

Solution

1. Step 1: Understand the purpose of reusable scripts

   Reusable test scripts help avoid writing the same code repeatedly, which saves time and reduces mistakes.

2. Step 2: Identify the correct benefit

   Among the options, only saving time and reducing errors matches the purpose of reusable scripts.

3. Final Answer:

   They save time and reduce errors by avoiding repeated code. -> Option A

4. Quick Check:

   Reusable scripts = save time and reduce errors [OK]

Hint: Reusable scripts avoid repeating code, saving time [OK]

Common Mistakes:

• Thinking reusable scripts slow down tests
• Believing reusable scripts only work for GET requests
• Confusing reusable scripts with writing duplicate code

2. Which of the following is the correct way to define a reusable function in a Postman test script?

easy

A. func checkStatus() { pm.test('Status is 200', () => pm.response.to.have.status(200)); }

B. def checkStatus() { pm.test('Status is 200', () => pm.response.to.have.status(200)); }

C. checkStatus() => { pm.test('Status is 200', () => pm.response.to.have.status(200)); }

D. function checkStatus() { pm.test('Status is 200', () => pm.response.to.have.status(200)); }

Solution

1. Step 1: Recall JavaScript function syntax

   In Postman scripts, JavaScript functions are defined using the keyword function followed by the function name and parentheses.

2. Step 2: Identify the correct syntax

   function checkStatus() { pm.test('Status is 200', () => pm.response.to.have.status(200)); } uses the correct JavaScript syntax. Options A, B, and C use invalid keywords or syntax not supported in JavaScript.

3. Final Answer:

   function checkStatus() { pm.test('Status is 200', () => pm.response.to.have.status(200)); } -> Option D

4. Quick Check:

   JavaScript function syntax = function name() {} [OK]

Hint: Use 'function' keyword to define reusable functions [OK]

Common Mistakes:

• Using Python or other language syntax like 'def'
• Using arrow function without assignment
• Using unsupported keywords like 'func'

3. Given the following Postman test script, what will be the output when the response status is 404?

function checkStatus() {
  pm.test('Status is 200', () => pm.response.to.have.status(200));
}

checkStatus();

medium

A. Test passes because the function runs without error.

B. Test fails because the response status is not 200.

C. Syntax error because function is not called correctly.

D. Test is skipped because status 404 is ignored.

Solution

1. Step 1: Understand the test logic

   The function checkStatus runs a test that expects the response status to be 200.

2. Step 2: Analyze the response status

   The actual response status is 404, which does not match 200, so the test will fail.

3. Final Answer:

   Test fails because the response status is not 200. -> Option B

4. Quick Check:

   Expected 200, got 404 = test fails [OK]

Hint: Test passes only if response status matches expected [OK]

Common Mistakes:

• Assuming function call causes syntax error
• Thinking test passes if function runs
• Believing 404 status is ignored automatically

4. You wrote this reusable test function in Postman but it does not run as expected:

function checkResponse() {
  pm.test('Response time is less than 200ms', () => {
    pm.expect(pm.response.responseTime).to.be.below(200);
  });
}

checkResponse

What is the error and how to fix it?

medium

A. Missing parentheses when calling the function; add () after checkResponse.

B. Incorrect assertion syntax; replace 'to.be.below' with 'to.be.lessThan'.

C. Function name is invalid; rename to 'check_response'.

D. Response time property is wrong; use 'pm.response.time' instead.

Solution

1. Step 1: Check function call syntax

   The function checkResponse is defined correctly but called without parentheses, so it does not execute.

2. Step 2: Fix the function call

   Adding parentheses () after checkResponse calls the function properly and runs the test.

3. Final Answer:

   Missing parentheses when calling the function; add () after checkResponse. -> Option A

4. Quick Check:

   Function call needs () to execute [OK]

Hint: Always add () to call functions in JavaScript [OK]

Common Mistakes:

• Confusing assertion syntax with chai library
• Changing function names unnecessarily
• Using wrong response time property

5. You want to reuse a test that checks if a JSON response has a specific key with a non-empty value. Which reusable function correctly implements this in Postman?

hard

A. function checkKeyExists(key) {
pm.test(`Response has key ${key}`, () => {
pm.expect(pm.response.json()[key]).to.exist;
});
}

B. function checkKeyExists(key) {
pm.test('Response has key', () => {
pm.expect(pm.response.json()).to.include.key(key);
});
}

C. function checkKeyExists(key) {
pm.test(`Response has key ${key}`, () => {
pm.expect(pm.response.json()).to.have.property(key).that.is.not.empty;
});
}

D. function checkKeyExists(key) {
pm.test(`Response has key ${key}`, () => {
pm.expect(pm.response.json()).to.have.key(key).not.empty;
});
}

Solution

1. Step 1: Understand the requirement

   The function must check that the JSON response has the given key and that its value is not empty.

2. Step 2: Analyze each option

   function checkKeyExists(key) { pm.test(`Response has key ${key}`, () => { pm.expect(pm.response.json()).to.have.property(key).that.is.not.empty; }); } uses correct chai assertions: to.have.property(key).that.is.not.empty which checks key existence and non-empty value.
   function checkKeyExists(key) { pm.test('Response has key', () => { pm.expect(pm.response.json()).to.include.key(key); }); } uses incorrect assertion to.include.key which is invalid.
   function checkKeyExists(key) { pm.test(`Response has key ${key}`, () => { pm.expect(pm.response.json()[key]).to.exist; }); } checks only existence but not if value is non-empty.
   function checkKeyExists(key) { pm.test(`Response has key ${key}`, () => { pm.expect(pm.response.json()).to.have.key(key).not.empty; }); } uses invalid chaining to.have.key(key).not.empty.

3. Final Answer:

   function checkKeyExists(key) { pm.test(`Response has key ${key}`, () => { pm.expect(pm.response.json()).to.have.property(key).that.is.not.empty; }); } -> Option C

4. Quick Check:

   Check key exists and not empty = function checkKeyExists(key) { pm.test(`Response has key ${key}`, () => { pm.expect(pm.response.json()).to.have.property(key).that.is.not.empty; }); } [OK]

Hint: Use 'to.have.property(key).that.is.not.empty' for key and value check [OK]

Common Mistakes:

• Using invalid chai assertion methods
• Checking only key existence without value
• Incorrect chaining of assertions