Interactions Reference

Run Test

Call another test from the same project, optionally passing arguments and overriding its run count. The composition primitive — build small tests, compose them into big tests.

Run Test calls another test from the current project. You can pass arguments for $placeholder substitution and override the called test's run count. It's the primary tool for building reusable building blocks (login, sign-up, navigate-to-cart) and composing them.

If any sub-run fails, the Run Test step is marked failed and any remaining sub-runs are skipped. Run history and costs for the called test stay attributed to the called test, so a login test called from 30 parents still shows up as one row in analytics.

Settings

The Run Test editor exposes:

Field	What it does
Referenced Test*	Pick the test to call from a dropdown of tests in the current project. Tests with parameters show a '(N params)' badge in the dropdown.
Parameters	Auto-detected from the selected test. Each $placeholder gets its own input field labeled with the parameter name.
Run Count	1–20. Default 1. Overrides the called test's own run count. Stops on first failure.

When the test's self-healing mode is Per Step, a per-step Self-healing toggle also appears.

The editor also surfaces an inline note: "This step runs another test in the same project. If that test contains terminate/open steps, it will affect app state."

Select Test to Run modal: Referenced Test picker showing 'login (2 params)' selected, two parameter fields ($email, $password), Run Count picker, Save and Cancel buttons.

What's possible

Composing a smoke flow: Run Test (login) → Run Test (browse-products) → Run Test (add-to-cart) → Run Test (checkout). Each is a single owned test you can develop and debug in isolation.
Data-driven testing: write a parameterized signup test with $email, $plan, then add several Run Test steps in a parent test, each with a different value set.
Repetition: Run Test (signup, Run Count = 20) to stress-test sign-up.
Inheriting self-healing: the called test inherits the parent test's self-healing mode if not overridden.

What's not possible

Calling a test from a different project — Run Test only sees tests within the current project. Cross-project reuse uses User-Defined templates instead.
Run Count above 20 — the picker is bounded. If you need more, chain multiple Run Test steps.
Conditional argument values — the parameters fields are static per Run Test step. To run the same test with different inputs, add multiple Run Test steps each with their own values.

Run Test vs. User-Defined

Both reuse logic. Pick Run Test when you want the called sequence to remain a separate, owned test with its own history. Pick User-Defined when you want the steps to be visible and editable inside the call site. See Reusing logic with templates.

Common patterns

Fixture tests. Author a setup test (Go Home → Terminate App → Open App) and Run Test it as the first step of every other test in the suite.
Parameter-driven matrix. Single purchase test with $amount, $plan, $paymentMethod. Parent test calls it once per matrix combination.
Run Count for stability. During development, set Run Count to 5 on a flaky Run Test step to see how often it actually fails.