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.