Output block in Postman - Framework Patterns

Framework Mode - Output block

Folder Structure

PostmanCollectionProject/
├── collections/
│   └── MyAPI.postman_collection.json
├── environments/
│   ├── dev.postman_environment.json
│   ├── staging.postman_environment.json
│   └── prod.postman_environment.json
├── tests/
│   └── outputBlockTests.js
├── scripts/
│   └── preRequestScripts.js
├── reports/
│   └── testReport.html
└── postman.config.json

Test Framework Layers

• Collections: Store API requests grouped by feature or service.
• Environments: Define variables like base URLs, tokens for different setups (dev, staging, prod).
• Tests: JavaScript files or inline scripts in Postman to validate API responses, including output blocks.
• Scripts: Pre-request or helper scripts to prepare data or set variables before requests.
• Reports: Generated test run reports showing pass/fail results and details.
• Config: Central configuration file for global settings like collection paths, environment selection, and report options.

Configuration Patterns

• Environment Variables: Use environment files to switch easily between dev, staging, and production URLs and credentials.
• Global Variables: Store reusable values like tokens or IDs accessible across collections.
• Collection Runner Settings: Configure iterations, delays, and data files for data-driven testing.
• Output Block Handling: Use test scripts to capture and assert output block values from API responses.
• CI/CD Integration: Use Newman CLI with config files to run collections and specify environments and reporters.

Test Reporting and CI/CD Integration

• Newman Reports: Generate HTML, JSON, or JUnit reports after running collections with Newman.
• CI/CD Pipelines: Integrate Newman runs in pipelines (GitHub Actions, Jenkins, GitLab CI) to automate tests on code changes.
• Output Block Validation: Test scripts log assertion results for output blocks, visible in reports.
• Notifications: Configure pipeline notifications on test failures or successes.

Best Practices

• Organize collections and environments clearly for easy maintenance and scalability.
• Write clear, simple test scripts to validate output blocks and other response data.
• Use environment variables to avoid hardcoding sensitive data and URLs.
• Automate test runs with Newman and integrate with CI/CD for continuous feedback.
• Keep test assertions deterministic and meaningful to catch real issues.

Self Check

Where would you add a new test script to validate the output block of an API response in this Postman framework structure?

Key Result

Organize Postman collections, environments, and test scripts to validate API output blocks with automated reporting.

Practice

1. What does the Output block in Postman primarily display after running a request?

easy

A. The list of saved environments

B. The raw API request headers only

C. The Postman app settings and preferences

D. The results of test scripts and any console logs

Solution

1. Step 1: Understand the purpose of the Output block

   The Output block shows what happened after running a request, including test results and logs.

2. Step 2: Identify what is NOT shown in the Output block

   Settings, environments, or just headers are not shown here; only test results and logs appear.

3. Final Answer:

   The results of test scripts and any console logs -> Option D

4. Quick Check:

   Output block = test results + logs [OK]

Hint: Output block shows test results and logs only [OK]

Common Mistakes:

• Confusing Output block with environment settings
• Thinking it shows only request headers
• Assuming it displays saved collections

2. Which of the following is the correct way to log a message to the Output block in a Postman test script?

easy

A. log('Test passed')

B. print('Test passed')

C. console.log('Test passed')

D. echo('Test passed')

Solution

1. Step 1: Recall JavaScript logging syntax in Postman

   Postman test scripts use JavaScript, and console.log() is the standard way to log messages.

2. Step 2: Identify incorrect logging functions

   Functions like print(), log(), and echo() are not valid in Postman scripts.

3. Final Answer:

   console.log('Test passed') -> Option C

4. Quick Check:

   Use console.log() to log messages [OK]

Hint: Use console.log() to print messages in Output block [OK]

Common Mistakes:

• Using print() instead of console.log()
• Trying to use echo() which is not JavaScript
• Forgetting parentheses in console.log

3. Given this Postman test script:

pm.test('Status code is 200', () => {
    pm.response.to.have.status(200);
});
console.log('Test completed');

What will you see in the Output block after running the request if the response status is 200?

medium

A. Test failed and no message

B. Test passed and 'Test completed' message

C. Only 'Test completed' message

D. No output at all

Solution

1. Step 1: Analyze the test script behavior

   The test checks if the response status is 200. If true, the test passes.

2. Step 2: Understand console.log output

   The console.log prints 'Test completed' regardless of test result.

3. Final Answer:

   Test passed and 'Test completed' message -> Option B

4. Quick Check:

   Passing test + console.log message = Test passed and 'Test completed' message [OK]

Hint: Passing test shows pass + console.log output [OK]

Common Mistakes:

• Assuming console.log only shows on failure
• Thinking test fails if console.log runs
• Ignoring test result messages

4. You wrote this Postman test script:

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

But after running, the Output block shows no test results or logs. What is the most likely problem?

medium

A. The test script is not saved or attached to the request

B. The response time is exactly 200ms, so test is skipped

C. console.log is not supported in Postman

D. The Output block only shows errors, not passes

Solution

1. Step 1: Check why Output block is empty

   If no test results or logs appear, the script might not be running at all.

2. Step 2: Confirm script attachment and saving

   Scripts must be saved and attached to the request to run and show output.

3. Final Answer:

   The test script is not saved or attached to the request -> Option A

4. Quick Check:

   Unsaved script = no output [OK]

Hint: Always save and attach test scripts to see output [OK]

Common Mistakes:

• Thinking console.log is unsupported
• Assuming Output block hides passing tests
• Believing test skips on exact boundary values

5. You want to verify in Postman that a JSON response contains a key userId with value 5, and log 'User verified' only if the test passes. Which test script will correctly show this in the Output block?

hard

A. pm.test('UserId is 5', () => {
pm.expect(pm.response.json().userId).to.eql(5);
});
if(pm.response.json().userId === 5) console.log('User verified');

B. pm.test('UserId is 5', () => {
pm.expect(pm.response.json().userId).to.eql(5);
console.log('User verified');
});

C. if(pm.response.json().userId === 5) {
pm.test('UserId is 5', () => {});
console.log('User verified');
}

D. pm.test('UserId is 5', () => {
pm.expect(pm.response.json().userId).to.eql(5);
});
console.log('User verified');

Solution

1. Step 1: Understand conditional logging requirement

   pm.test callbacks always execute fully; assertions don't halt execution. Log only on pass requires a matching condition.

2. Step 2: Analyze options

   A: unconditional log after test - always logs.
   B: log inside pm.test - executes even if assertion fails.
   C: empty pm.test - no proper verification.
   D: proper assertion test + matching if condition - logs only if userId === 5 (test passes).

3. Final Answer:

   pm.test('UserId is 5', () => { pm.expect(pm.response.json().userId).to.eql(5); }); if(pm.response.json().userId === 5) console.log('User verified'); -> Option A

4. Quick Check:

   if() matching test condition = log only on pass [OK]

Hint: Use if() matching assertion after pm.test for log only on pass [OK]

Common Mistakes:

• Putting console.log inside pm.test (runs on fail too)
• Logging unconditionally outside pm.test
• Using empty pm.test callback