Collection Runner
Every request so far has been sent one at a time, by hand, by clicking Send. That's fine while
you're building a collection, but it doesn't scale to actually testing the RecipeBox API — you want
to run every request in the RecipeBox API collection, in order, in one pass,
and see a single summary of what passed and what failed. That's exactly what the
Collection Runner does. It can also repeat a single request multiple times with
different input values pulled from a data file — handy for testing the same endpoint against a
batch of realistic inputs instead of just one hardcoded example.
Running a Whole Collection
- Click the collection name (
RecipeBox API) in the sidebar, then click Run (or open the Runner from the "..." menu). - The Runner opens with every request in the collection listed, in the same order they appear in the collection, each with a checkbox.
- Pick which Environment to run against (e.g.
dev-environment), leave Iterations at1for a plain run-through, and click Run RecipeBox API. - Postman fires each request in sequence —
Login, thenCreate Recipe, thenGet Recipe by ID, and so on — running every test script attached to each one, exactly as if you'd clicked Send on each request yourself in order.
This matters because request order can be meaningful: Login has to run before any
request that depends on {{token}}, and Create Recipe has to run before
a later Get Recipe by ID that depends on the {{recipeId}} it saved. The
Runner respects the collection's folder/request order, so a well-organized collection (folders
named by feature, requests ordered logically within each) is also a collection that runs
correctly end to end.
Running with a Data File
Say you want to test the Search Recipes request
(GET {{baseUrl}}/recipes/search?q={{query}})
against several different search terms, not just one. Instead of editing the request five times,
create a CSV data file:
query,expectedMinResults
paneer,1
biryani,1
zzzznotarealdish,0
soup,1
cake,1
In the request's Tests tab, read each row's values through pm.iterationData:
var jsonData = pm.response.json();
var expectedMin = parseInt(pm.iterationData.get("expectedMinResults"));
pm.test("status is 200", function () {
pm.response.to.have.status(200);
});
pm.test("result count meets expectation for this query", function () {
pm.expect(jsonData.results.length).to.be.at.least(expectedMin);
});
Back in the Runner: select only the Search Recipes request, click Select File
under Data, choose the CSV, and Postman automatically sets Iterations to 5 — one
per row. Each iteration substitutes that row's query and expectedMinResults
into the request via {{query}} and the test script above, so the same request runs
five times with five different real inputs in a single click.
Reading the Pass/Fail Summary
When the run finishes, the Runner shows a summary: total requests sent, total assertions run, and a pass/fail count for each. Each iteration is listed separately so you can see exactly which row of the CSV — which search term, in this example — caused a failure, rather than just an overall "something failed" message.
| Summary field | What it tells you |
|---|---|
| Total Requests | How many requests were actually sent across all iterations (5 iterations × 1 request = 5 here) |
| Total Assertions | Every pm.test() across every request/iteration, tallied as passed vs. failed |
| Per-request / per-iteration rows | Expand any row to see exactly which assertion failed and why, with the actual vs. expected values |
A run where every row is green tells you the whole collection — or the whole data set — behaves correctly in one pass. A red row tells you precisely which iteration and which assertion to investigate first, instead of having to re-run requests one by one to find the failure.
ingredients list per iteration) that doesn't flatten cleanly into CSV columns.