Runtime Flow View

The Runtime Flow View is the live picture of a test case run. It opens
when you start a run from the test case page, click into a run from the
history list, or drill into a test_case item on a Test Plan
run. It is the same view whether the run finished a second ago or two
weeks ago — the difference is whether it keeps updating in front of you.

About URLs in examples: all examples use localhost:5770 as the default
Mockarty address. If your instance runs on a remote server, replace
localhost:5770 with its actual address.

Related pages: Test Case Steps ·
Test Case Management ·
Step Execution Modal ·
Test Plans

What you see

The view is a vertical tree of cards — one card per step — with the case
header at the top and an environment summary in the right rail.

  Case: Login regression                 RUNNING  · started 14:22:08

  ├── 1  REQUEST   Login                       PASS    300ms   ▸ expand
  ├── 2  REQUEST   Fetch profile               RUN     …       ▸ expand
  │       waiting on: Login
  └── 3  MANUAL    Verify welcome email        PENDING

Click any card to expand it. The body fills with everything the step did:
the resolved request, the response, harvested values, and (for manual
steps) the verdict + comment.

[Runtime flow view — full run — screenshot pending]

Reading the flow tree

Status chips

The colour and word on each step card is its live status:

Micro-chips inside the card

Small chips in the card header describe what happened during resolution
before the request fired:

• Key icon and name — the environment bound to the step. Expand the card
  to see its name with the other binding details. Older events without a saved
  name show a generic Environment label.
• A number with o beside the adjustments icon (for example, 2o) —
  count of active step overrides.
• A number with s beside the lock icon (for example, 1s) — count of
  resolved secret references. Secret
  values are not shown in this section.

The card body

• Request — fully resolved URL, method, headers, body. Every
  {{plan.X}}, {{env.X}}, override and secret has been substituted, so
  you see exactly what went on the wire. Secrets show as *** with a
  tooltip “from secret store: ”.
• Response — status, headers, body, duration. Bodies larger than the
  display cap show a “view raw” link that downloads the full payload.
• Extracted — every value the step’s extract rules wrote to the run’s
  plan context. Each row shows the rule kind, the from expression, and
  the resulting plan.<key> value. Downstream steps use these.
• Expectations — pass / fail breakdown for every assertion the linked
  request defines. A red row tells you precisely which expectation broke.
• Attempts — for steps that re-tried (e.g. inside a retry policy), one
  collapsible row per attempt with its own request / response / verdict.

What a yellow “waiting” chip really means

A step in WAITING state is gated by its dependsOn. The card body has
one line: waiting on: <upstream step name>. As soon as the upstream step
flips to PASS, the yellow chip turns blue and the step starts. If the
upstream flips to FAIL, the waiting step turns grey SKIPPED with
the reason dependency failed: <upstream>.

A waiting step is not stalled or broken — it is the runner being honest
about parallel ordering.

Environment snapshot panel

The right rail of the runtime view holds the environment snapshot for
the whole run. This is the resolved environment captured at the moment the
case run started, frozen for the life of the run.

It lists:

• the bound environment’s name (or a generic label for older runs);
• every variable the environment defined at run start, with its value;
• every secret alias the run used. Secret values are not stored in the
  snapshot.

The panel shows the values captured at run start; editing an environment
later does not change this snapshot.

The snapshot is the source of truth for “what env did this run actually
use”. Two weeks from now, when you wonder why an old run hit
api.staging-eu.example.com instead of the current api.staging.example.com,
the snapshot panel tells you exactly that.

Live updates — what each event means

The runtime view subscribes to a live stream from the server. You’ll see
events flow through naturally; you do not need to refresh.

If the connection drops, the view tries to reconnect silently. The reconnected
view re-syncs from the server snapshot, so you never lose state — at most you
miss the animation of an intermediate transition.

Sequential debug controls

When the run was started in debug mode (see Test Case Steps §8),
the runtime view shows a sticky bar at the bottom after every step:

• Continue — release the pause and run the next step (or the next
  layer of parallel steps).
• Continue & edit — open an editor that lets you tweak the harvested
  plan-context values, the next step’s overrides, or the next step’s
  request body before resuming. The change is written into the run’s
  history so the trail of what you did is preserved.
• Stop — cancel the run. Completed steps keep their results; the run
  ends in cancelled.

The same controls are available on a non-debug run if you click Pause
in the run menu — the run stops at the next step boundary and the bar
appears.

Sharing and exporting a finished run

Every run has a permanent URL of the shape:

https://mockarty.example.com/ui/test-cases/runs/<run-id>

Send the URL to anyone with read access on the namespace and they see the
same view, fully reconstructed from server data. There is no “snapshot at
share time” — the link always shows the run’s final state (or live state
if you share before the run finishes).

The header has a kebab menu with three export actions:

• Copy link — copies the permanent URL.
• Export run (JSON) — downloads a JSON dump with every step’s
  request, response, harvested values, environment snapshot, and timing.
  Use this for offline reporting or to feed downstream tools.
• Open Allure report — only visible when the case run was triggered as
  part of a Test Plan. Opens the plan’s merged Allure
  report, with this case’s steps already deep-linked.

Permissions and namespace isolation

• Reading the runtime view (snapshot + live updates) requires test_case:read
  on the namespace that owns the case.
• Operating the Continue / Stop controls requires test_case:write.
• Cross-namespace access is not allowed — a user who can read namespace
  acme cannot see runs from namespace globex, even if they have the
  permanent URL.
• Secrets shown as *** are never written to the run history, the export
  JSON, or the audit trail. The audit trail records only the alias names
  and the source store names.

Next: the Test Case Steps page is the
how-to for building the cases you’ll watch here. The
Step Execution Modal page covers the manual-verdict
flow in detail.