Skip to main content

​
What rerun does

Rerun re-executes a test using what’s already saved — no new plan generation, no new code generation. This makes rerun the primary iteration loop once a test exists: fix code, rerun, read the verdict, repeat.

​
Rerunning a test

Without --wait, the command returns once the rerun is accepted. With --wait, it blocks until passed, failed, blocked, or cancelled — same exit codes as test run --wait. Control the polling ceiling:

​
Rerunning many

Rerun every test in a project at once:
Useful flags for batch rerun: Example — rerun only the tests that failed, filtered to the checkout group:

​
Backend dependency closure

When you rerun a backend test, the CLI expands the run to include:
  1. Producer tests — any test that --produces a variable the named test --needs.
  2. The named test itself.
  3. Teardown tests — any test tagged --category teardown in the same project.
This ensures the test runs in a valid environment, not against stale or missing upstream state. To skip the expansion and rerun just the named test in isolation:
Important: --skip-dependencies can cause a backend test to fail if it relies on data created by a producer test. Use it only when you know the required fixtures are already in place.

​
Auto-heal

Auto-heal is on by default for every frontend rerun, on every plan tier, when triggered through the CLI. When your app’s UI has shifted since the test was last written — a button was renamed, a form gained an extra field, navigation was restructured — the verbatim script would fail even though the underlying feature still works. Auto-heal detects that drift and repairs the script so the test passes. If the feature itself is broken, the test stays failed.
Auto-heal is on by default for all CLI reruns. It consumes a small amount of credit only when healing actually repairs a step — a clean verbatim replay that passes is free. Opt out with --no-auto-heal. See Billing & Plans for current rates.
To opt out for a specific rerun:
Auto-heal is ignored for backend tests — backend test failures are almost always real assertion or fixture issues, not UI drift.
Minor UI refactors that moved or renamed things. A button relabeled from “Continue” to “Next”, a sidebar collapsed into a hamburger menu, a custom dropdown replaced with a design-system component. The feature still works; the saved script just refers to stale selectors or text. Auto-heal re-binds the test to the new UI in context and marks it passed.
A real product bug. The form rejects valid input, an API returns 500, the redirect lands on the wrong page. Auto-heal will attempt recovery and fail — the test stays failed. This is the correct outcome: auto-heal absorbs UI drift; it does not mask genuine regressions. Pull the failure bundle (testsprite test failure get <test-id>) to triage what actually broke.

​
Credits

When your credit balance is insufficient, the command exits with code 12. Top up credits in the Portal under Settings → Billing.

Exit Codes

See the full list of exit codes and what each one means.

​
Where to Go Next

Running Tests

Trigger fresh runs, override the target URL, and understand the full exit-code table

Reading Results

Pull failure bundles, step logs, and run history after a rerun

Exit Codes

Exit 12 and everything else the CLI can emit

Agent Integration

Wire the rerun loop into your coding agent’s verify-fix cycle