Why variables avoid hardcoding in Postman - Framework Benefits

Framework Mode - Why variables avoid hardcoding

Folder Structure of a Postman Test Project

  PostmanProject/
  ├── collections/
  │   └── MyAPI.postman_collection.json
  ├── environments/
  │   ├── dev.postman_environment.json
  │   ├── staging.postman_environment.json
  │   └── prod.postman_environment.json
  ├── globals/
  │   └── globals.postman_globals.json
  ├── scripts/
  │   ├── pre-request-scripts.js
  │   └── test-scripts.js
  ├── README.md
  └── postman.config.json
  

Test Framework Layers in Postman

• Collections: Group of API requests organized by feature or endpoint.
• Environments: Store variables like URLs, tokens, or user data for different setups (dev, staging, prod).
• Globals: Variables accessible across all environments and collections.
• Scripts: Pre-request scripts to set variables or prepare data, and test scripts to validate responses.
• Configuration: Settings for running collections, such as environment selection and iteration count.

Configuration Patterns to Avoid Hardcoding

• Use Environment Variables: Define base URLs, API keys, and user credentials in environment files instead of writing them directly in requests.
• Global Variables: Use for values shared across multiple environments or collections.
• Variable Scopes: Postman supports local, environment, and global scopes to control variable visibility and override.
• Parameterize Requests: Use variables in request URLs, headers, and bodies with {{variableName}} syntax.
• Secure Sensitive Data: Store secrets in environment variables and avoid committing them to version control.

Test Reporting and CI/CD Integration

• Newman CLI: Run Postman collections from command line with environment variables passed as parameters.
• Reports: Generate HTML or JSON reports from Newman runs to see pass/fail results and test details.
• CI/CD Integration: Integrate Newman runs in pipelines (Jenkins, GitHub Actions) using environment files to switch contexts without code changes.
• Version Control: Store collections and environment files in Git, excluding sensitive data or using encrypted secrets.

Best Practices for Avoiding Hardcoding in Postman

1. Always use variables for dynamic data: URLs, tokens, user info should come from variables, not fixed strings.
2. Organize environments clearly: Separate dev, test, and prod environments to avoid accidental data mix-up.
3. Use descriptive variable names: Makes it easier to understand and maintain tests.
4. Keep sensitive data out of code: Use environment variables and secure storage to protect secrets.
5. Reuse variables across requests: Avoid duplication and simplify updates.

Self Check Question

Where in this Postman framework structure would you add a new variable for the API base URL to avoid hardcoding it in requests?

Key Result

Use environment and global variables in Postman to avoid hardcoding and make tests flexible and secure.

Practice

1. Why is it better to use variables instead of hardcoding values in Postman tests?

easy

A. Variables increase the size of the test script.

B. Variables slow down the test execution.

C. Hardcoding values prevents errors.

D. Variables make tests easier to update and reuse.

Solution

1. Step 1: Understand the role of variables in tests

   Variables store values that can be reused, avoiding repeated fixed values.

2. Step 2: Compare variables with hardcoding

   Hardcoding requires changing each instance manually, while variables update all uses at once.

3. Final Answer:

   Variables make tests easier to update and reuse. -> Option D

4. Quick Check:

   Variables improve maintainability = A [OK]

Hint: Variables save time by updating all values at once [OK]

Common Mistakes:

• Thinking variables slow down tests
• Believing hardcoding reduces errors
• Assuming variables increase script size unnecessarily

2. Which of the following is the correct way to use a variable in a Postman request URL?

easy

A. https://api.example.com/users/{{userId}}

B. https://api.example.com/users/$userId

C. https://api.example.com/users/userId

D. https://api.example.com/users/{userId}

Solution

1. Step 1: Recall Postman variable syntax

   Postman uses double curly braces {{variableName}} to insert variables.

2. Step 2: Identify correct URL format

   Only https://api.example.com/users/{{userId}} uses {{userId}} correctly to reference the variable.

3. Final Answer:

   https://api.example.com/users/{{userId}} -> Option A

4. Quick Check:

   Use {{variable}} syntax = C [OK]

Hint: Remember variables use {{ }} in Postman URLs [OK]

Common Mistakes:

• Using $variable instead of {{variable}}
• Writing variable name without braces
• Using single braces instead of double

3. Given the environment variable baseUrl set to https://api.test.com, what will be the full request URL if the request uses {{baseUrl}}/items?

medium

A. https://api.test.com/items

B. {{baseUrl}}/items

C. https://api.test.com{{baseUrl}}/items

D. items/{{baseUrl}}

Solution

1. Step 1: Substitute the variable with its value

   The variable {{baseUrl}} is set to https://api.test.com, so it replaces {{baseUrl}} in the URL.

2. Step 2: Form the full URL

   Replacing {{baseUrl}} with https://api.test.com gives https://api.test.com/items.

3. Final Answer:

   https://api.test.com/items -> Option A

4. Quick Check:

   Variable replaced by value = B [OK]

Hint: Replace {{variable}} with its value to get full URL [OK]

Common Mistakes:

• Leaving variable as is without substitution
• Concatenating variable incorrectly
• Misplacing variable in URL path

4. You have a test script using a variable token but the test fails because the token is not replaced. What is the most likely cause?

medium

A. The test script does not support variables.

B. The variable token was not defined in the environment or collection.

C. The token value is too long for Postman to handle.

D. The variable name was typed correctly with double curly braces.

Solution

1. Step 1: Check variable definition

   If a variable is not defined in environment or collection, Postman cannot replace it.

2. Step 2: Rule out other causes

   Correct syntax and script support are usually not the problem; token length is not a typical issue.

3. Final Answer:

   The variable token was not defined in the environment or collection. -> Option B

4. Quick Check:

   Undefined variable causes no replacement = D [OK]

Hint: Check if variable is defined before running tests [OK]

Common Mistakes:

• Assuming syntax error causes missing variable
• Blaming token length for failure
• Ignoring variable scope and definition

5. You want to run the same Postman test on different servers without changing the request URL manually. How does using variables help achieve this?

hard

A. Hardcoding the URL is faster than using variables.

B. Variables automatically detect the server location without setup.

C. By storing the server URL in a variable, you can switch environments easily.

D. Variables prevent the test from running on multiple servers.

Solution

1. Step 1: Understand environment switching

   Using a variable for the server URL allows changing its value per environment without editing requests.

2. Step 2: Explain benefit of variables

   This makes tests reusable and easy to run on different servers by just switching variable values.

3. Final Answer:

   By storing the server URL in a variable, you can switch environments easily. -> Option C

4. Quick Check:

   Variables enable environment flexibility = A [OK]

Hint: Use variables to switch servers without editing requests [OK]

Common Mistakes:

• Thinking variables auto-detect servers
• Believing hardcoding is faster
• Assuming variables limit test runs