Test Scenarios

Test scenarios chain existing test cases into a multi-step workflow, such as registering a user, logging in, creating an order and verifying it. Steps run sequentially, and each step can extract values from its response that later steps reuse. That makes scenarios the tool for end-to-end flows a single request cannot cover.

Where scenarios live

Open Test Runner from the sidebar. The left panel is split into two collapsible sections, with Suites on top and Scenarios below. The search box above filters both sections at once, and each scenario shows a badge with its step count.

Use the + button on the Scenarios header, labelled New scenario or folder, to create a New Scenario or a New Folder. Creating scenarios and folders requires the tests:write permission.

Creating a scenario

1. In the Scenarios section, click + and choose New Scenario.
2. Enter a Name such as User Registration Flow, and an optional Description.
3. Add Tags to organize and filter your test scenarios.
4. Click Create Scenario.

Right-click a scenario for its context menu, which holds Run Scenario, Rename and Delete. Deleting a scenario also deletes all of its steps, while the underlying test cases are untouched.

Organizing scenarios in folders

Folders keep large scenario collections navigable and can be nested. Each folder has a name and an optional icon, and the context menu offers Rename / Edit, New Sub-folder and Delete. Deleting a folder moves its scenarios and sub-folders to the parent, or to the root, and the scenarios themselves are not deleted. Drag scenarios and folders to reorganize the tree, and drag a folder onto the Drop here to move to root zone to un-nest it.

Building the step list

Selecting a scenario opens its detail view in the center panel. Until you add steps, you see No steps yet with an Add Your First Step button.

Adding steps

1. Click Add Step.
2. Pick a test suite. The dialog lists every suite with its case count.
3. Search or browse the suite's test cases and click Add next to each case you want. The dialog stays open, so you can add several steps from different suites in one go.

A step is a reference to an existing test case, so its request, assertions and response extractions are maintained in one place. Edit the case and every scenario that uses it picks up the change.

Wait steps

Click Add Wait to insert a pause between steps, which helps with APIs that have eventual consistency or rate limits. Wait steps display their duration on the card, reading something like Wait 500ms. Click that label to change the duration, which accepts 0 to 300000 ms.

A wait step counts as a step. It appears in the results table and in the run history as a row named Wait, carrying its duration, and it always passes. It has no request, so there is no detail view behind it.

Managing steps

Action	How
Open the step	Click the step's name on the card. See The step dialog below.
Reorder	Drag a step by its handle to a new position. Steps always execute top to bottom.
Enable / disable	Toggle the switch on the step card. Disabled steps are dimmed and don't execute.
Delete	Click the trash icon on the step card.
Add a condition	Click the branch icon, or the Conditional badge, on the step card.

The step dialog

Clicking a step's name opens everything that step is made of.

Step settings are the parts that belong to this step, and all of them are editable here:

Setting	Notes
Test case	Change picks another case. The step keeps its position, condition and enabled state.
Duration	Wait steps only, accepting 0 to 300000 ms.
Enabled	Same switch as on the card.
Condition	Opens the condition editor, with autocomplete over the variables earlier steps produce.

Test case configuration is read-only, because a test case is shared and editing it would change every other scenario that uses it. It shows the request's method and URL, the assertions, and the two variable sides:

• Variables in lists every {{variable}} the request and assertions reference, each with where it comes from. That is either an earlier step, named with its step number and the extracting path, or the environment. A variable that no earlier step sets is flagged. The common case is one that a later step produces, which only surfaces as a failed run otherwise. Reordering steps changes this immediately.
• Variables out lists what this step extracts for later steps, with its source path.

If the test case has a pre-request script, coverage is reported without warnings, because a script can define variables that cannot be detected by reading the request.

Passing values between steps

Chaining works through response extractions defined on the test cases you use as steps. When a step runs, its extractions store values as variables, and any later step can reference them with {{variableName}}. That works in URLs, headers, bodies, assertions and step conditions.

An extraction has a source, a path where applicable, and a variable name:

Source	What it captures	You provide
Response Body	A value from the JSON body, selected with a JSONPath expression	JSONPath (e.g. $.data.id) + variable name
Response Header	A specific response header's value	Header name (e.g. Authorization) + variable name
Status Code	The HTTP status code of the response	Variable name only

The test case editor also offers the quick-add buttons Store Status Code, Store Header and Store JSON Value, which create the corresponding extraction with one click. Extractions can be reordered and removed in the extraction table.

A typical chain runs in two steps. Step 1 calls POST /users and extracts $.id into userId, then step 2 calls GET /users/{{userId}} and asserts on the result.

Conditional steps

Any step can carry a condition that decides whether it executes or is skipped, based on variables extracted by earlier steps. Click the branch icon on a step card to open the Step Condition editor:

Field	Meaning
Variable	The variable to test, in placeholder syntax, such as {{prevStatus}} or {{userId}}.
Operator	One of ==, !=, >, <, >=, <=.
Value	The value to compare against, such as 200.
When true	Whether a true comparison means execute this step or skip this step. The other branch always does the opposite.

The editor previews the resulting rule, and steps with a condition show a Conditional badge. Use Clear to remove a condition. Skipped steps are reported with their skip reason in the results.

Switch to the JSON tab to write the raw condition instead, in the same shape the API accepts:

{ "if": "{{prevStatus}} == 200", "then": "execute", "else": "skip" }

A condition the builder cannot express opens in JSON mode automatically, so it stays intact. That covers anything other than {{variable}} <operator> value. Each condition holds one comparison, because there is no AND or OR, and a condition the evaluator cannot parse runs the step.

Running a scenario

1. Pick the target environment with the environment selector in the scenario toolbar, because every step uses that environment's base URL and authentication.
2. Optionally open Run settings (the gear next to the run button) to change how the run behaves:

Setting	Options
On Error	Stop is the default and halts at the first failed step. Ignore runs every step regardless, and Abort cancels the whole run.
Save run to history	On by default. Turn it off for a dry run, where results stay in the Results tab and no entry is written to the run history.

The settings are remembered and apply to both run entry points, which are the toolbar button and the scenario context menu. 3. Click Run Scenario. Running requires the tests:execute permission.

Steps execute sequentially. A progress bar tracks completion, and each step card's colored left edge shows its live status:

State	On the card
Queued	Waiting its turn, with the card dimmed and a muted edge.
Running	Blue edge, plus a spinner badge that updates in real time.
Passed	Green edge and a result pill with the status code and duration.
Failed	Red edge and a result pill naming the failed assertions.
Skipped	Yellow edge and a Skipped badge. Hover it for the skip reason.
Pending	Amber edge and pill. The step's case is a contract test whose endpoint the environment does not serve yet, which is not a failure. See Contract Testing.
Blocked	Muted edge and a Blocked pill. The target environment is read-only and this step's case writes, so nothing was sent, and this is not a failure either. See Test Suites for the switch and the exact refusal message.

If the run ends before every step ran, which happens under On Error → Stop or Abort, the steps it never reached go back to showing no indicator rather than staying queued.

Running a scenario from its context menu in the sidebar executes the same run without live progress, and so does running it through the API or an AI agent over MCP. The cards and the results table fill in once the whole run returns. That is deliberate rather than a stalled run, because live progress needs the scenario open in the center panel.

Reading the results

The Results tab in the right panel shows the run as a run-overview table, with one row per step in execution order, filling in live as the scenario runs:

• A status icon reading queued, running, passed, failed, skipped, pending or blocked.
• The step name with the response's HTTP status-code badge.
• An inline failure reason, or skip reason, right on the row, so a red step explains itself without a click.
• Vars in for the variables the step consumed, and Extracted for the variables it captured for later steps.
• The step duration.

Above the table, a summary bar carries the passed, failed and skipped counts plus the total duration. Pending and blocked steps get their own counts there whenever a run produced any, and neither is ever folded into the failed count. The completion toast reads the same way, saying "2 passed · 1 blocked" rather than showing a red run. A scenario in which no step was ever sent comes back as a neutral notice instead of a success.

Click any row to load that step's full detail below the table, which is the resolved request, assertion results, response body and every extracted variable. Routebase focuses the first failed step automatically, so a failing run opens on the step that broke.

Before the first run, the panel shows No results yet with the line "Execute the scenario to see step-by-step results here."

Run history

The History tab lists past scenario runs with their status, relative timestamp, pass and fail and skip summary, and duration. Click a run to load its full step-by-step results into the Results tab, which helps when comparing a failing run against the last green one.

A stored run keeps three outcomes per step, which are passed, failed and skipped. Pending and blocked steps are recorded as failed there, because the distinction is not part of what a scenario run stores. A live run does draw it, so run the scenario again to see which steps were never sent rather than genuinely broken.

A historical run is no longer a thinner version of the live one. Each step keeps its actual request with the resolved URL, headers and body, alongside the assertion results, the response body and its size, the extracted variables, and the pre-request and post-response script console output. Runs recorded before that shipped never stored those fields, so their step detail opens without the request and console sections. There is no backfill, and the next run of the scenario carries the full record.

Related

• Test Suites — the test cases your steps are built from
• Test Data — fixtures and seeds to set up state before a flow
• Environments — the base URLs and credentials scenarios run against
• Data-Driven Tests — running one case across many data rows