Run order and flow control in Postman - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Postman Collection Run Order Behavior

Given a Postman collection with three requests named A, B, and C, where B depends on a variable set by A, and C depends on a variable set by B, what is the order in which the requests run during a collection run?

A C runs first, then B, then A

B B runs first, then A, then C

C A runs first, then B, then C

D All requests run in parallel

💡 Hint

Think about how Postman handles dependencies between requests in a collection run.

Postman runs requests in the order they appear in the collection. Since B depends on a variable set by A, A must run first. Similarly, C depends on B, so C runs last.

❓ assertion

intermediate

Correct Assertion to Check Response Status

In a Postman test script, which assertion correctly checks that the response status code is 200?

A pm.test('Status code is 200', () => pm.response.status === 200);

B pm.test('Status code is 200', () => pm.response.statusCode === '200');

C pm.test('Status code is 200', () => pm.response.statusCode == 200);

D pm.test('Status code is 200', () => pm.response.to.have.status(200));

💡 Hint

Look for the correct Postman assertion syntax for status code.

Option D uses the correct Postman Chai assertion syntax. Options A, C, and D either use incorrect properties or compare types incorrectly.

🔧 Debug

advanced

Why Does This Postman Test Fail?

Consider this Postman test script: pm.test('Response has userId', () => { pm.expect(pm.response.json().userId).to.eql(123); }); The test fails even though the response JSON is {"userId": 123}. What is the most likely reason?

Postman

pm.test('Response has userId', () => {
  pm.expect(pm.response.json().userId).to.eql(123);
});

A The userId in response is a string, not a number

B The response is not parsed as JSON because Content-Type header is missing or incorrect

C The pm.expect syntax is incorrect

D The test script runs before the response is received

💡 Hint

Check how Postman parses response bodies based on headers.

If the response Content-Type header is missing or not application/json, pm.response.json() may fail or not parse correctly, causing the test to fail.

❓ framework

advanced

Controlling Request Execution Flow in Postman Collection Runner

Which Postman feature allows you to control the flow of requests during a collection run, such as skipping or repeating requests based on conditions?

A Using pm.setNextRequest() in test scripts

B Using environment variables only

C Using pre-request scripts to delay requests

D Using the Postman monitor scheduling

💡 Hint

Think about how to programmatically decide which request runs next.

pm.setNextRequest() lets you specify the next request to run, enabling conditional flow control in collection runs.

🧠 Conceptual

expert

Effect of pm.setNextRequest(null) in Postman Collection Run

What happens when pm.setNextRequest(null) is called inside a test script during a Postman collection run?

A The collection run stops immediately after the current request

B The collection run restarts from the first request

C The next request in the collection runs as usual

D The current request is retried

💡 Hint

Consider what setting next request to null means for the runner.

Calling pm.setNextRequest(null) tells Postman to stop running any further requests after the current one finishes.

Practice

1. In Postman, what does pm.setNextRequest() do in a collection run?

easy

A. It sets which request runs next in the collection.

B. It stops the entire collection run immediately.

C. It restarts the current request.

D. It logs the response of the current request.

Solution

1. Step 1: Understand the purpose of pm.setNextRequest()

   This function controls the flow by specifying the next request to run in the collection.

2. Step 2: Compare other options

   Stopping the run is done by pm.setNextRequest(null), not this function. Restarting or logging are unrelated.

3. Final Answer:

   It sets which request runs next in the collection. -> Option A

4. Quick Check:

   Flow control = set next request [OK]

Hint: Remember: setNextRequest controls next request flow [OK]

Common Mistakes:

• Confusing pm.setNextRequest() with stopping the run
• Thinking it restarts the current request
• Assuming it logs data instead of controlling flow

2. Which of the following is the correct syntax to stop running any further requests in a Postman collection?

easy

A. pm.abortRun()

B. pm.setNextRequest('stop')

C. pm.stopCollection()

D. pm.setNextRequest(null)

Solution

1. Step 1: Identify the method to stop collection run

   Postman uses pm.setNextRequest(null) to stop running further requests.

2. Step 2: Verify other options

   Other options like pm.stopCollection() or pm.abortRun() do not exist in Postman scripting.

3. Final Answer:

   pm.setNextRequest(null) -> Option D

4. Quick Check:

   Stop run = setNextRequest(null) [OK]

Hint: Use null in setNextRequest to stop run [OK]

Common Mistakes:

• Using a string like 'stop' instead of null
• Assuming non-existent functions stop the run
• Confusing stopping with skipping requests

3. Consider this Postman test script inside a request named 'Request A':

if (pm.response.code === 200) {
  pm.setNextRequest('Request B');
} else {
  pm.setNextRequest(null);
}

What happens if the response code is 404?

medium

A. The collection run continues to 'Request B'.

B. An error is thrown and the run fails.

C. The collection run stops after 'Request A'.

D. The collection run restarts from the first request.

Solution

1. Step 1: Analyze the condition for response code 404

   Since 404 is not 200, the else block runs pm.setNextRequest(null).

2. Step 2: Understand effect of pm.setNextRequest(null)

   This stops the collection run immediately after the current request.

3. Final Answer:

   The collection run stops after 'Request A'. -> Option C

4. Quick Check:

   404 triggers stop = setNextRequest(null) [OK]

Hint: If condition false, setNextRequest(null) stops run [OK]

Common Mistakes:

• Assuming it continues to next request regardless
• Thinking it restarts the collection
• Believing an error is thrown automatically

4. You wrote this test script in Postman:

pm.setNextRequest('Request C');
pm.setNextRequest(null);

What is the effect on the collection run flow?

medium

A. The run jumps to 'Request C' and then stops.

B. The run stops immediately; 'Request C' is skipped.

C. The run ignores both commands and continues normally.

D. The run loops infinitely between requests.

Solution

1. Step 1: Understand order of pm.setNextRequest calls

   Only the last pm.setNextRequest() call takes effect in a single script execution.

2. Step 2: Analyze the last call pm.setNextRequest(null)

   This stops the collection run immediately, ignoring previous setNextRequest calls.

3. Final Answer:

   The run stops immediately; 'Request C' is skipped. -> Option B

4. Quick Check:

   Last setNextRequest call wins = null stops run [OK]

Hint: Last setNextRequest call controls flow [OK]

Common Mistakes:

• Thinking both calls run in sequence
• Assuming first call overrides last
• Believing it causes infinite loops

5. You want to run a Postman collection where:
- If 'Login' request succeeds (status 200), run 'GetData'.
- If 'Login' fails, stop the run.
- After 'GetData', always run 'Logout'.

Which sequence of pm.setNextRequest() calls in the 'Login' and 'GetData' test scripts achieves this flow?

hard

A. In 'Login': pm.setNextRequest('GetData') if 200 else pm.setNextRequest(null);In 'GetData': pm.setNextRequest('Logout')

B. In 'Login': pm.setNextRequest('Logout') always;In 'GetData': pm.setNextRequest(null)

C. In 'Login': pm.setNextRequest(null) always;In 'GetData': pm.setNextRequest('Logout')

D. In 'Login': pm.setNextRequest('GetData') always;In 'GetData': pm.setNextRequest(null)

Solution

1. Step 1: Control flow after 'Login'

   If status is 200, next request should be 'GetData'; else stop run with pm.setNextRequest(null).

2. Step 2: Control flow after 'GetData'

   Always run 'Logout' next, so pm.setNextRequest('Logout') is set in 'GetData' tests.

3. Final Answer:

   In 'Login': pm.setNextRequest('GetData') if 200 else pm.setNextRequest(null); In 'GetData': pm.setNextRequest('Logout') -> Option A

4. Quick Check:

   Conditional jump + final logout = In 'Login': pm.setNextRequest('GetData') if 200 else pm.setNextRequest(null);
   In 'GetData': pm.setNextRequest('Logout') [OK]

Hint: Use conditional setNextRequest in Login, fixed next in GetData [OK]

Common Mistakes:

• Setting wrong next request after Login
• Not stopping run on Login failure
• Skipping Logout after GetData