What if your tests could smartly react to any response without you lifting a finger?
Why Default and conditional responses in Postman? - Purpose & Use Cases
Start learning this pattern below
Jump into concepts and practice - no test required
Imagine testing an API manually by sending requests and checking each response one by one to see if it matches expected results.
You have to remember what response to expect for each input and write notes for different cases.
This manual way is slow and tiring because you must repeat many steps for each condition.
It's easy to miss errors or forget to check some cases, leading to bugs slipping through.
Using default and conditional responses in Postman lets you automate how your tests react to different API replies.
You can set rules to handle expected and unexpected responses automatically, saving time and reducing mistakes.
Send request -> Check response manually -> Note if pass or fail
pm.test('Status is 200', () => pm.response.to.have.status(200)); pm.test('Handle 404', () => { if(pm.response.code === 404) { pm.expect(pm.response.json().error).to.eql('Not Found'); } });
It enables fast, reliable testing that adapts automatically to different API responses without extra manual checks.
When testing a login API, you can automatically check if a successful login returns a 200 status and if a wrong password returns a 401 error, all in one test script.
Manual checking is slow and error-prone.
Default and conditional responses automate response handling.
This leads to faster, more accurate API testing.
Practice
Solution
Step 1: Understand the role of conditional responses
Conditional responses allow testing different API replies based on conditions in one place.Step 2: Identify the main purpose
This helps verify various outcomes without writing separate tests for each response.Final Answer:
To check different API responses in one test script -> Option CQuick Check:
Default and conditional responses = test multiple replies [OK]
- Confusing response testing with sending requests
- Assuming it changes API endpoints
- Mixing testing with documentation generation
Solution
Step 1: Review Postman test syntax
Postman uses pm.test with a callback function and pm.expect for assertions.Step 2: Identify correct assertion for status code
pm.expect(pm.response.code).to.equal(200) correctly asserts status code equals 200.Final Answer:
pm.test('Status is 200', () => { pm.expect(pm.response.code).to.equal(200); }); -> Option BQuick Check:
pm.expect with .to.equal(200) = correct syntax [OK]
- Using '==' instead of .to.equal() in assertions
- Checking pm.response.status instead of pm.response.code
- Not calling pm.expect properly inside pm.test
pm.test('Check response', () => {
if (pm.response.code === 200) {
pm.expect(pm.response.json().success).to.be.true;
} else {
pm.expect(pm.response.code).to.equal(404);
}
});Solution
Step 1: Analyze the if-else condition with status 404
Status 404 triggers the else block which asserts pm.response.code equals 404.Step 2: Check assertion in else block
pm.expect(pm.response.code).to.equal(404) will pass since status is 404.Final Answer:
Test passes because status is 404 and matches else condition -> Option AQuick Check:
404 status triggers else assertion = pass [OK]
- Assuming test fails due to missing success property
- Thinking JSON parsing fails on 404
- Ignoring else block assertions
pm.test('Status check', () => {
if (pm.response.code = 201) {
pm.expect(pm.response.code).to.equal(201);
} else if (pm.response.code = 400) {
pm.expect(pm.response.json().error).to.exist;
}
});Solution
Step 1: Check if condition syntax
The code uses '=' which assigns value instead of '===' for comparison.Step 2: Understand impact of assignment in conditions
Assignment always returns true, causing logic errors and wrong test behavior.Final Answer:
Using assignment '=' instead of comparison '===' in if conditions -> Option DQuick Check:
Use '===' for comparisons, not '=' [OK]
- Confusing '=' with '==' or '==='
- Ignoring that assignment returns a value
- Not validating all possible status codes
Solution
Step 1: Check correct use of comparison operators
pm.test('Conditional response test', () => { if (pm.response.code === 200) { pm.expect(pm.response.json().data).to.exist; } else if (pm.response.code === 404) { pm.expect(pm.response.json().error).to.exist; } else { pm.expect.fail('Unexpected status code'); } }); uses '===' for comparisons correctly. Using '=' causes assignment instead of comparison.Step 2: Verify conditional logic and assertions
The code checks 'data' field existence for status 200, 'error' for 404, and explicitly fails for unexpected codes using pm.expect.fail().Step 3: Evaluate other options
One option incorrectly combines status and field checks in single pm.expect statements, causing failures. Another does not condition on status codes at all.Final Answer:
pm.test('Conditional response test', () => { if (pm.response.code === 200) { pm.expect(pm.response.json().data).to.exist; } else if (pm.response.code === 404) { pm.expect(pm.response.json().error).to.exist; } else { pm.expect.fail('Unexpected status code'); } }); -> Option AQuick Check:
Use if-else with '===' and proper assertions [OK]
- Using '=' instead of '===' in conditions
- Combining conditions inside one pm.expect
- Not handling unexpected status codes
