Reusable test scripts in Postman - Deep Dive

Overview - Reusable test scripts

What is it?

Reusable test scripts are pieces of code written once and used multiple times across different API requests or test collections in Postman. They help automate checks on API responses to ensure they work as expected. Instead of rewriting the same test logic repeatedly, you write it once and call it wherever needed. This saves time and keeps tests consistent.

Why it matters

Without reusable test scripts, testers must write the same checks repeatedly for each API endpoint, which wastes time and risks mistakes or inconsistencies. Reusable scripts make testing faster, easier to maintain, and less error-prone. This leads to more reliable APIs and faster delivery of software that works well.

Where it fits

Before learning reusable test scripts, you should understand basic API testing and how to write simple tests in Postman. After mastering reusable scripts, you can explore advanced test organization, environment variables, and continuous integration of tests.

Mental Model

Core Idea

Reusable test scripts let you write test code once and run it many times to check API responses consistently and efficiently.

Think of it like...

It's like writing a recipe for a cake once and using it every time you want to bake, instead of figuring it out from scratch each time.

Reusable Test Scripts Structure
┌─────────────────────────────┐
│ 1. Define reusable test code  │
│    (e.g., function or script) │
├─────────────────────────────┤
│ 2. Call reusable code in      │
│    multiple API requests      │
├─────────────────────────────┤
│ 3. Run tests automatically    │
│    on each API response       │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Basics of Postman Tests

Concept: Learn how to write simple tests in Postman to check API responses.

In Postman, you write tests in the Tests tab using JavaScript. For example, to check if the response status is 200, you write: pm.test('Status is 200', () => { pm.response.to.have.status(200); }); This runs after the API response and passes if the status is 200.

Result

The test passes if the API returns status 200; otherwise, it fails and shows an error.

Understanding how to write basic tests is essential before making them reusable.

2

Foundation

Understanding Test Script Duplication

Concept: Recognize the problem of repeating the same test code in many requests.

If you want to check the response time is less than 500ms in many requests, you might write: pm.test('Response time < 500ms', () => { pm.expect(pm.response.responseTime).to.be.below(500); }); in every request's Tests tab. This repetition wastes time and risks inconsistency.

Result

You end up with many copies of the same test code scattered across requests.

Seeing this repetition highlights the need for reusable test scripts.

3

Intermediate

Creating Reusable Functions in Postman

🤔Before reading on: do you think reusable test code must be global or can it be local to requests? Commit to your answer.

Concept: Learn to write reusable test functions in the Postman Pre-request or Tests scripts that can be called multiple times.

You can define a function in the Pre-request Script or Tests tab like: function checkStatus200() { pm.test('Status is 200', () => { pm.response.to.have.status(200); }); } Then call checkStatus200() in multiple requests' Tests scripts to reuse the logic.

Result

The same test logic runs wherever you call the function, avoiding duplication.

Knowing that functions can hold reusable test logic lets you organize tests better.

4

Intermediate

Using Postman Collection-Level Scripts

🤔Before reading on: do you think collection-level scripts run before or after individual request tests? Commit to your answer.

Concept: Postman allows scripts at the collection level that run for every request inside it, enabling reuse of test code across many requests.

In the Postman Collection settings, you can add Tests scripts that run after every request in that collection. For example: pm.test('Response time < 500ms', () => { pm.expect(pm.response.responseTime).to.be.below(500); }); This test runs automatically for all requests in the collection.

Result

You write the test once and it applies to all requests in the collection.

Collection-level scripts provide a powerful way to apply common tests without repeating code.

5

Intermediate

Sharing Scripts via Postman Environments

Concept: Use environment variables to store and share reusable test code snippets across requests.

You can save reusable test code as a string in an environment variable: pm.environment.set('checkResponseTime', "pm.test('Response time < 500ms', () => { pm.expect(pm.response.responseTime).to.be.below(500); });"); Then in Tests tab, run: eval(pm.environment.get('checkResponseTime')); This runs the stored test code dynamically.

Result

Reusable test code is stored centrally and can be updated once to affect many requests.

Using environment variables for code sharing is flexible but requires careful handling to avoid errors.

6

Advanced

Modularizing Tests with External Libraries

🤔Before reading on: do you think Postman supports importing external JavaScript libraries directly? Commit to your answer.

Concept: Postman supports adding external libraries like Lodash via the Sandbox API, enabling modular and reusable test utilities.

You can include Lodash in your tests by referencing it: const _ = require('lodash'); Then write reusable utility functions using Lodash to simplify test code. For example: function isValidUser(response) { return _.has(response, 'user.id') && _.isString(response.user.name); } Use isValidUser() in multiple tests.

Result

Tests become cleaner and more powerful by leveraging external libraries for reusable logic.

Knowing how to use external libraries expands your ability to write reusable, maintainable tests.

7

Expert

Automating Reusable Tests in CI/CD Pipelines

🤔Before reading on: do you think reusable test scripts in Postman can run automatically outside the Postman app? Commit to your answer.

Concept: Postman tests, including reusable scripts, can be run automatically in Continuous Integration pipelines using Newman, Postman's command-line runner.

You export your Postman collection with reusable tests and run: newman run collection.json in your CI pipeline. This runs all tests automatically on every code change, catching issues early without manual effort.

Result

Reusable tests run consistently and automatically, improving software quality and delivery speed.

Integrating reusable tests into CI/CD pipelines ensures tests are always run and maintained, preventing regressions.

Under the Hood

Postman runs test scripts in a JavaScript sandbox environment after receiving an API response. Reusable test scripts are functions or code blocks stored in collection-level scripts, environment variables, or external libraries. When a request runs, Postman executes these scripts in order, allowing shared code to run before or after individual request tests. This modular execution model enables code reuse and consistent test application.

Why designed this way?

Postman was designed to simplify API testing for developers and testers by allowing modular, reusable scripts to reduce duplication and errors. Early versions required repeating tests, which was inefficient. Introducing collection-level scripts and environment variables for code sharing balanced flexibility and ease of use without complex setup. This design supports both beginners and advanced users.

Postman Test Execution Flow
┌───────────────┐
│ API Request   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ API Response  │
└──────┬────────┘
       │
       ▼
┌─────────────────────────────┐
│ 1. Request-level Tests       │
│ (Specific tests run here)    │
└──────┬──────────────────────┘
       │
       ▼
┌─────────────────────────────┐
│ 2. Collection-level Tests    │
│ (Reusable scripts run here) │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do reusable test scripts in Postman automatically run for all requests without setup? Commit yes or no.

Common Belief: Reusable test scripts run automatically for all requests once defined anywhere.

Reality: Reusable scripts only run automatically if placed in collection-level scripts or properly called; defining a function in one request does not share it globally.

Why it matters: Assuming automatic sharing leads to tests silently not running, causing false confidence in API quality.

Quick: Can you store complex JavaScript functions directly in environment variables safely? Commit yes or no.

Common Belief: You can safely store and run any JavaScript code in environment variables for reuse.

Reality: Storing code as strings in environment variables and running with eval() is risky and error-prone; syntax errors or injection risks can break tests.

Why it matters: Misusing environment variables for code can cause hard-to-debug failures and security issues.

Quick: Do collection-level tests run before or after request-level tests? Commit your answer.

Common Belief: Collection-level tests run before request-level tests.

Reality: Collection-level tests run after request-level tests, allowing shared checks to run last.

Why it matters: Misunderstanding execution order can cause test conflicts or missed checks.

Quick: Does using external libraries in Postman tests require internet access at runtime? Commit yes or no.

Common Belief: External libraries in Postman tests load from the internet every time tests run.

Reality: Postman bundles some libraries like Lodash internally; no internet is needed at runtime for these, ensuring stable test runs.

Why it matters: Expecting internet access can cause confusion and test failures in offline or CI environments.

Expert Zone

1

Reusable test scripts should avoid side effects like modifying global variables to prevent unpredictable test behavior.

2

Using Postman’s pm.* API consistently in reusable scripts ensures compatibility and easier debugging across environments.

3

Stacking multiple reusable scripts requires careful ordering to avoid test conflicts or overwriting results.

When NOT to use

Reusable test scripts are less suitable for highly unique or one-off tests that require custom logic. In such cases, writing specific tests per request is better. Also, avoid overusing eval() for code reuse due to security and maintenance risks.

Production Patterns

In professional teams, reusable test scripts are organized in collection-level Tests scripts and shared libraries. They integrate with Newman in CI pipelines for automated regression testing. Teams use environment variables to configure tests per environment (dev, staging, prod) while keeping test logic reusable.

Connections

Modular programming

Reusable test scripts apply the modular programming principle to testing code.

Understanding modular programming helps grasp why breaking tests into reusable parts improves maintainability and clarity.

Continuous Integration (CI)

Reusable test scripts enable efficient automated testing in CI pipelines.

Knowing CI concepts shows how reusable tests speed up feedback loops and improve software quality.

Manufacturing assembly lines

Reusable test scripts are like standardized quality checks repeated at multiple points on an assembly line.

Seeing tests as repeated quality gates clarifies why reuse saves effort and ensures consistent product quality.

Common Pitfalls

#1 Writing the same test code in every request instead of reusing.

Wrong approach:

pm.test('Status is 200', () => {
pm.response.to.have.status(200);
});
// repeated in every request's Tests tab

Correct approach:

In collection-level Tests script:
pm.test('Status is 200', () => {
pm.response.to.have.status(200);
});

Root cause:

Not knowing collection-level scripts exist or how to use them.

#2 Storing complex test functions as strings in environment variables and running with eval() without validation.

Wrong approach:

pm.environment.set('testFunc', "pm.test('Check', () => { pm.expect(true).to.be.true; });");
eval(pm.environment.get('testFunc'));

Correct approach:

Define reusable functions in collection-level scripts or Pre-request scripts and call them directly without eval().

Root cause:

Misunderstanding environment variables as code storage and risks of eval().

#3 Assuming reusable scripts run globally without explicit calls or placement.

Wrong approach:

Defining a function in one request's Tests tab and expecting it to run in others without calling or sharing.

Correct approach:

Place reusable functions in collection-level scripts or shared libraries and call them explicitly in requests.

Root cause:

Confusing scope and execution context in Postman scripts.

Key Takeaways

Reusable test scripts let you write test code once and run it many times, saving effort and ensuring consistency.

Postman supports reusable tests via collection-level scripts, functions, and environment variables, each with pros and cons.

Understanding script execution order and scope is key to effective reuse and avoiding silent test failures.

Integrating reusable tests into CI pipelines automates quality checks and speeds up software delivery.

Avoid risky practices like eval() for code reuse; prefer structured, modular scripts for maintainability and security.