A test suite is a named group of test cases that you run together as a launch. All cases run in parallel, each in its own cloud browser, so the suite finishes about as fast as its slowest case. Use suites to bundle the flows that belong together: a critical-path set that gates every PR, a full regression set that runs nightly and before deployment, or a per-area set for one part of your product.

What a suite is

A suite has a short name and a list of member test cases. When you save it, Robusty assigns a short ID (slug) shown in its settings.

Field	What it is
Name	A short, human label for the suite (e.g. "Critical path"). Must be unique within the project.
Test cases	The cases that belong to the suite. Add or remove them from the suite editor.
ID	The suite's slug, generated on save. Used by the CLI and CI to launch the suite.

Suites and test cases are a many-to-many relationship: a suite holds many test cases, and a single test case can belong to several suites at once. Adding a case to a suite doesn't copy it — the same case runs in every suite it belongs to, so you maintain the description in one place.

Organizing cases into suites

Open Test suites in the project sidebar and create a suite, then add cases to it from the editor. Two patterns cover most projects:

A broad suite that contains every test case, for full regression runs.
One or more focused suites that contain only the most important flows, for fast feedback on every change.

Because a case can live in multiple suites, keep each critical case in both a focused suite and the broad one — you don't have to choose.

Examples

`All tests`

Every test case in the project. This is your full regression run that gives you the maximum coverage but consumes more of your run quota, so run it before the release or on a schedule (for example nightly) rather than on every commit.

`Critical path`

A small suite with only the flows that tend to break often. Wire it into CI/CD to run on every commit in a PR as a quality gate before the merge.

Running a suite

A suite is the unit you launch. There are three ways to trigger a run, and each produces a launch:

Trigger	How
Manual	Run suite in the suite editor, or the run button on the suites list.
Schedule	A recurring schedule attached to the suite (see below).
CLI	`robusty launch --suite <id>` from your terminal or CI/CD.

A launch runs every test case in the suite and reports a per-test verdict.

Since cases run in parallel, keep them independent — one case shouldn't rely on another. Give each its own data (for example a fresh {{RANDOM_EMAIL}} per signup) so runs never collide.

When you run a suite manually you can supply per-launch variable overrides — for example point {{PROJECT_URL}} at a preview URL instead of staging. The CLI accepts the same overrides with --var KEY=VALUE. This lets one suite run unchanged against any environment.

robusty launch --suite <id> --var PROJECT_URL=https://pr-34.example.com

Scheduling a suite

Each suite can carry one recurring schedule. Open the suite and use the Schedule card to turn it on and pick a frequency. The next-run preview updates as you edit; save to apply. Scheduled runs appear in launches with a schedule trigger.

Notes on scheduling:

Runs start on the hour — you choose the hour of the day, not the minute.
The schedule uses the timezone of the browser you save it from.
Scheduled launches draw from the same monthly run quota as manual and CLI runs. A busy hourly schedule on a large suite can consume it quickly.

Failure notifications

When a scheduled or CLI-triggered launch fails, Robusty can send an email alert so a broken flow doesn't go unnoticed between deploys. Configure recipients under Settings → Notifications for the project.

Delete a suite

Deleting a suite removes the suite and its schedule. It does not delete the member test cases — they remain in the project and in any other suites they belong to. Past launches for the suite are kept as history.

Open the suite.
Click Delete suite and confirm.

Test Suites