Using Chai assertion library in Postman - Framework Patterns

Framework Mode - Using Chai assertion library

Folder Structure

postman-project/
├── collections/
│   └── api-requests.postman_collection.json
├── environments/
│   ├── dev.postman_environment.json
│   └── prod.postman_environment.json
├── tests/
│   ├── auth-tests.js
│   └── user-tests.js
├── utils/
│   └── helpers.js
├── config/
│   └── config.json
└── README.md

This structure organizes Postman collections, environment files, test scripts using Chai assertions, utility helpers, and configuration.

Test Framework Layers

• Collections: Store API requests grouped by feature or service.
• Environments: Define variables like base URLs, tokens for different setups.
• Tests: JavaScript files with Chai assertions to validate API responses.
• Utils: Helper functions for common tasks like token generation or data formatting.
• Config: Central place for environment-specific settings and credentials.

Configuration Patterns

• Environment Variables: Use Postman environment files to switch between dev, test, prod easily.
• Global Variables: Store reusable values like auth tokens or user IDs.
• Config File: JSON file to hold URLs, credentials, and other settings accessed by test scripts.
• Dynamic Data: Use pre-request scripts to generate or fetch data before tests run.

Test Reporting and CI/CD Integration

• Newman CLI: Run Postman collections from command line with detailed reports.
• Reporters: Use reporters like HTML, JSON, or JUnit formats for readable test results.
• CI/CD: Integrate Newman runs in pipelines (GitHub Actions, Jenkins) to automate tests on code changes.
• Alerts: Configure notifications on test failures to keep the team informed.

Best Practices

1. Use Clear Assertions: Write simple and meaningful Chai assertions to check API responses.
2. Keep Tests Independent: Each test should run alone without relying on others.
3. Reuse Code: Put common logic in utils to avoid repetition.
4. Manage Secrets Securely: Never hardcode credentials; use environment variables.
5. Consistent Naming: Name collections, tests, and variables clearly for easy understanding.

Self Check

Where in this folder structure would you add a new test script to verify the login API using Chai assertions?

Key Result

Organize Postman API tests with collections, environment configs, and Chai assertions for clear, maintainable validation.

Practice

1. What is the main purpose of using the Chai assertion library in Postman tests?

easy

A. To create user interface elements

B. To write clear and readable checks for API responses

C. To send HTTP requests faster

D. To store environment variables

Solution

1. Step 1: Understand Chai's role in testing

   Chai is used to write assertions that check if API responses meet expectations.

2. Step 2: Identify the correct purpose in Postman context

   In Postman, Chai helps create readable tests that verify API behavior.

3. Final Answer:

   To write clear and readable checks for API responses -> Option B

4. Quick Check:

   Chai assertions = readable API checks [OK]

Hint: Chai is for checking API results clearly [OK]

Common Mistakes:

• Confusing Chai with request sending
• Thinking Chai creates UI elements
• Mixing Chai with environment variable storage

2. Which of the following is the correct syntax to assert that the response status code is 200 using Chai in Postman?

easy

A. pm.expect(response.code).to.equal(200);

B. pm.expect(pm.response.status).to.equal(200);

C. pm.expect(pm.response.code).to.equal(200);

D. pm.expect(response.status).to.be(200);

Solution

1. Step 1: Identify the correct Postman response object

   The response object in Postman is accessed via pm.response.

2. Step 2: Use Chai syntax to check status code

   The correct Chai assertion is pm.expect(pm.response.code).to.equal(200);.

3. Final Answer:

   pm.expect(pm.response.code).to.equal(200); -> Option C

4. Quick Check:

   Status code check uses pm.response.code [OK]

Hint: Use pm.response.code with to.equal for status [OK]

Common Mistakes:

• Using wrong object like response.code
• Using to.be instead of to.equal
• Missing pm.response prefix

3. Given this Postman test code:

pm.test('Check response body', () => {
  pm.expect(pm.response.text()).to.include('success');
});

What will happen if the response body is 'Operation was successful'?

medium

A. Test will pass only if response code is 200

B. Test will fail because 'success' is not exactly matched

C. Test will throw a syntax error

D. Test will pass because 'success' is included in the response

Solution

1. Step 1: Understand the assertion used

   The assertion checks if the response text includes the substring 'success'.

2. Step 2: Check if 'success' is in 'Operation was successful'

   The word 'successful' contains 'success' as a substring, so the assertion passes.

3. Final Answer:

   Test will pass because 'success' is included in the response -> Option D

4. Quick Check:

   Substring check includes 'success' [OK]

Hint: Include checks pass if substring exists anywhere [OK]

Common Mistakes:

• Expecting exact match instead of substring
• Confusing syntax error with assertion failure
• Assuming status code affects this test

4. Identify the error in this Postman test code snippet:

pm.test('Status is 404', () => {
  pm.expect(pm.response.status).to.equal(404);
});

medium

A. pm.response.status is not the correct property for status code

B. to.equal should be to.be.equal

C. pm.test should be pm.expect

D. Missing semicolon after pm.test

Solution

1. Step 1: Check the property used for status code

   The correct property for status code in Postman is pm.response.code, not pm.response.status.

2. Step 2: Confirm Chai syntax correctness

   The to.equal syntax is correct and pm.test is used properly.

3. Final Answer:

   pm.response.status is not the correct property for status code -> Option A

4. Quick Check:

   Status code property is pm.response.code [OK]

Hint: Use pm.response.code for status, not pm.response.status [OK]

Common Mistakes:

• Using pm.response.status instead of pm.response.code
• Adding unnecessary 'to.be' in assertion
• Confusing pm.test with pm.expect

5. You want to write a Postman test that asserts the JSON response has a property userId with a value greater than 100. Which code snippet correctly uses Chai assertions to do this?

hard

A. pm.test('userId > 100', () => {
const jsonData = pm.response.json();
pm.expect(jsonData.userId).to.be.above(100);
});

B. pm.test('userId > 100', () => {
const jsonData = pm.response.json();
pm.expect(jsonData.userId).to.equal(100);
});

C. pm.test('userId > 100', () => {
pm.expect(pm.response.text()).to.include('userId > 100');
});

D. pm.test('userId > 100', () => {
pm.expect(pm.response.code).to.be.above(100);
});

Solution

1. Step 1: Parse JSON response correctly

   Use pm.response.json() to get the response as an object.

2. Step 2: Use Chai's 'above' assertion on userId property

   Check that jsonData.userId is greater than 100 with to.be.above(100).

3. Final Answer:

   pm.test('userId > 100', () => { const jsonData = pm.response.json(); pm.expect(jsonData.userId).to.be.above(100); }); -> Option A

4. Quick Check:

   Parse JSON then assert property above value [OK]

Hint: Parse JSON then use to.be.above for numeric checks [OK]

Common Mistakes:

• Using to.equal instead of to.be.above
• Checking response text instead of JSON property
• Checking status code instead of userId