Collection runner

The collection runner executes every request in a folder (or an entire collection) one after another. Pre-request scripts fire before each send, captures thread response values into variables for the next request, and post-response script assertions produce per-request pass/fail verdicts - all shown live as the run progresses.

Opening the runner

Click any folder or collection in the sidebar to open its page as a tab. The page has a Run button in the toolbar. Clicking it opens the runner panel for that scope: if you click a folder, only the requests inside that folder (and its subfolders) run; if you click the collection root, every request in the collection runs.

Requests are executed in the order they appear in the sidebar - the same order controlled by the seq field in each .tiger file. Drag requests in the sidebar to change that order before running.

How a run works

The runner processes items sequentially, never in parallel. For each request:

1. Pre-request script runs first (if the request has one). The script can read and write variables using tiger.setVar / tiger.getVar. Any variable it sets is available to the URL, headers, body and auth of this request and every request that follows.
2. The request is sent with the current variable set applied via {{variable}} interpolation.
3. Captures extract values from the response (status code, a header, or a JSON body path) and write them into named variables. Those variables are available to all subsequent requests in the same run.
4. Post-response script runs (if present). It can inspect tiger.response, set more variables, and declare named assertions with tiger.test.
5. The request is marked passed when the HTTP status is below 400 and every tiger.test assertion in the post-response script passed. Requests with no script tests pass on the status code alone.

If a pre-request script throws, or a transport error occurs, the request is marked failed with the error message and the runner moves on to the next item. The shared variable state at the point of failure is preserved so subsequent requests still have everything captured so far.

A Stop button is available while the run is in progress. Clicking it signals the runner to skip remaining requests after the current one finishes. The summary reports how many items were completed and marks the run as stopped.

Live results panel

As each request settles the runner panel updates immediately - you do not wait for the whole run to finish before seeing results. Each row shows:

• Request name and HTTP method.
• HTTP status code and response time in milliseconds.
• A PASS or FAIL badge.
• Individual test names and their pass/fail state, when the request has script assertions.
• The error message if a script or transport error aborted the request.

A summary bar at the top of the panel shows the running total of passed and failed requests and updates after each item.

Writing assertions

Assertions live in the post-response script. The scripting API is the same as for individual requests - see Scripting for the full reference. The key method for the runner is tiger.test:

// Post-response script on any request
tiger.test("status is 201", () => {
  tiger.expect(tiger.response.status === 201, `got ${tiger.response.status}`)
})

tiger.test("response has an id", () => {
  tiger.expect(tiger.response.json.id != null, "id is missing")
})

tiger.test("responds under 500 ms", () => {
  tiger.expect(tiger.response.timeMs < 500, `took ${tiger.response.timeMs} ms`)
})

tiger.test(name, fn) registers a named assertion. If fn throws, the test is recorded as failed with the thrown message. tiger.expect(condition, message) is a convenience that throws when the condition is falsy.

Scripts run in a sandboxed Function scope. They cannot access fetch, require, process, DOM globals, or any other ambient host API - only the tiger object and console.log (output appears in the script console, not the terminal).

Chaining requests with captures

The runner shares a single variable map across all requests in the run. Captures declared in the .tiger file (or via the Captures tab in the editor) automatically feed that map as each response arrives. A common pattern: authenticate first, capture the token, then use it in every subsequent request.

A minimal example using the .tiger format directly:

meta {
  name: Login
  seq: 1
}

post {
  url: {{baseUrl}}/auth/token
}

body:json {
  { "client_id": "{{clientId}}", "client_secret": "{{clientSecret}}" }
}

capture {
  accessToken: body.access_token
}

The next request in the folder can reference {{accessToken}} in its auth:bearer block or anywhere else. The runner writes the captured value immediately after the response arrives, before the next request's pre-script runs.

A typical test workflow

A practical sequence for testing a REST resource lifecycle:

1. Request 1 - POST /items: create a resource. Capture body.id into createdId. Assert status 201 and that id is present.
2. Request 2 - GET /items/{{createdId}}: fetch the resource. Assert status 200 and that the returned name matches what was sent.
3. Request 3 - PUT /items/{{createdId}}: update it. Assert status 200 and that the updated field reflects the change.
4. Request 4 - DELETE /items/{{createdId}}: delete it. Assert status 204.
5. Request 5 - GET /items/{{createdId}}: confirm deletion. Assert status 404.

Run the folder. The live panel shows each row going green as the run progresses. If step 3 fails, steps 4 and 5 still run (the runner does not stop on failure by default), so you see the full picture before investigating.

Environment selection

The runner uses whichever environment is currently active in the environment selector at the top of the window. Switch environments before clicking Run to target a different API base URL or credential set. The runner takes a snapshot of the variable map at the moment the run starts; changing the environment mid-run has no effect on the in-progress execution.

Stopping a run

Click Stop in the runner panel while a run is in progress. The runner finishes the request currently in flight, then halts. The summary panel shows the partial results and marks the run as stopped. You can re-run immediately using the same Run button.

Runner vs performance runner

The collection runner is for correctness: it runs each request once, in sequence, and grades pass/fail. The performance runner is for load: it fires N requests at a configurable concurrency level and reports min, max, avg, p50 and p95 timings. They are separate tools on the same collection/folder page.

Related pages