Postman Test Runner
You use the postman test runner by selecting a collection and running its requests in sequence. This tool sends each API call and checks the response against your test scripts. Teams often store shared keys inside workspace variables to make these test runs fast. Still, shared keys with broad roles let anyone run unsafe requests against live systems. How the postman test runner works The runner takes a group of saved API requests and runs them one by one. You can pick the order of the calls b
Test Runner: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use the postman test runner by selecting a collection and running its requests in sequence. This tool sends each API call and checks the response against your test scripts. Teams often store shared keys inside workspace variables to make these test runs fast. Still, shared keys with broad roles let anyone run unsafe requests against live systems.
How the postman test runner works
The runner takes a group of saved API requests and runs them one by one. You can pick the order of the calls before you start the run. Each request sends data to your server and waits for an answer back. After the server replies, the tool runs small scripts to check the status and payload.
Teams use variable sets to switch between local, staging, and live servers. You load a data file to pass different values into each loop of the run. One request can read a token from a reply and save it for the next call. This setup lets you test full user flows from log in to data updates.
You can run these checks on your own machine or in a build pipeline. Local runs help developers check code changes before they share their work with the team. Pipeline runs check the API every time someone merges new code into the main branch. Both methods rely on the same saved collections and variable sets to work.
Why variable permissions leave a security gap
Workspace roles decide who can view or edit collections and variables inside the app. You can limit a team member to a reader role so they cannot change shared tests. This native setup stops accidental edits to your test suites and shared variable lists. It also helps teams share common API setups without copying files by hand.
Still, workspace roles only control who can log in and click run in the app. They do not check what the actual API requests do while they are in flight. A test collection often holds an admin key so it can set up test data. Anyone who can run that collection can use that admin key to send delete calls.
Test Runner: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
When a test hits a real server, the response might include sensitive user records. Standard test logs can store raw emails, phone numbers, card numbers, or national IDs. If you share those test results across the team, everyone sees that private data. Native runner settings decide who starts a run, not what data comes back in results.
Managing data files and test state
Good test runs depend on clean input data and predictable server states. Teams often link a text or table file to feed fresh values into each test loop. Each row in the file represents one full pass through your chosen request list. The runner reads a row, puts the values into variables, and sends the calls.
If a test writes new records to a database, the next run might fail on duplicates. Engineers add cleanup requests at the end of a collection to remove test records. These cleanup steps need high permissions to delete rows or reset tables on the server. Keeping those high permissions safe during normal test runs is a constant challenge for teams.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How do I change the order of requests in a test run?
You can drag and drop requests inside the runner window before you start the run. You can also uncheck specific calls if you want to skip them during that pass.
Can the runner use external data files for loops?
Yes, you can attach a data file before you start the collection run. The tool reads each row and swaps the values into your request variables for each loop.
Why do my tests pass one by one but fail in the runner?
Full runs often fail because an earlier request changes data that a later request needs. Check your scripts to make sure each step cleans up or passes the right variables forward.