Skip to main content

Inspecting a test

List tests in a project, optionally filtered:

Status is per environment

test list and test get without --env show each frontend test’s latest result in the project’s default environment, and --status filters on that, not on the latest run in any environment. Use --env <name> to read another environment. A --target-url run is recorded under its temporary environment and does not change the listed status. project list and project get show the default environment and environment count.

Step-by-step results

test steps returns the step log of the latest run, or of a specific run:
Each entry has the step name, its status (passed or failed), and its run. Use --page-size and --max-items for long logs. Steps logged before run IDs were tracked are excluded when you pass --run-id.

The latest result

Without --env or --history, this shows the newest run across all environments, even if still running. In text output, if that run is not on the Default environment, a line follows with the Default environment’s status and the command to read that environment’s history (omitted with --output json, --env, --history, or when the Default status cannot be read). --env requires --history. --include-analysis adds the AI triage block: root-cause hypothesis, recommended fix target, failure kind, and the snapshotId tying all artifacts together.
For backend tests the result also carries the captured stdout (apiOutput) and Python traceback (trace): full under --output json (and in failure bundles as result.json / failure.json), a 20-line tail of each in text mode.

Run history

targetUrl is the address the run started against and stays that way after an environment URL edit; URL userinfo is removed before storage. If a new run still visits an old host, check the saved test steps (Environments).

Triaging a failure

For a failed test, start with the one-screen triage card (status, failure kind, root-cause hypothesis, recommended fix target):
To pull the full failure bundle to disk:
--out creates the bundle directory but not its parent; a missing parent exits 5. Without --out, the bundle prints to stdout. The bundle holds the failing step, DOM snapshots as text, test source, and root-cause analysis, all tied to one snapshotId (see Failure Bundle). --failed-only keeps only the failing step and its neighbors (±1) for faster agent context loading.

Pinning to a specific run

test failure get always returns the latest failing run, which moves when a new run arrives. To pin an exact run:
Without --out, the bundle goes to ./.testsprite/runs/<run-id>/ (directories created). With --out <dir>, the parent of <dir> must exist. The bundle is immutable, so a concurrent Portal or schedule run cannot overwrite it. Use test failure get <test-id> for interactive triage and test artifact get <run-id> in scripts and CI.

When there is no bundle

The bundle includes the test’s saved code. A frontend test gets saved code when it passes against a public URL; a tunnel (--local) run never saves code. If the test has never passed, or has only run through a tunnel, test failure get and test artifact get exit 4 with reason no_code. A cancelled run exits 4 with cancelled_no_artifacts. In both cases test steps --run-id <run-id> and test failure summary <test-id> still work. Backend bundles contain saved code and failure analysis (with stdout and traceback when available) but no step log. Use test artifact get <run-id>; on the V3 execution path test failure get <test-id> also returns backend bundles.

Reading test code

Without --out the code prints to stdout; the file’s parent directory must exist. The response includes the language, framework, code, and a codeVersion token that protects testsprite test code put from overwriting a concurrent edit.

Where to Go Next

Running Tests

Trigger runs, wait for verdicts, and understand exit codes

Rerun & Auto-Heal

Re-run a test or let AI repair UI drift

Key Terms

runId, codeVersion, snapshotId, and the rest of the vocabulary

Command Reference

Full flag listing for every CLI command