Suites tab
What the Suites tab is
Section titled “What the Suites tab is”The Suites tab of the Test Explorer (/tests?view=suites) lets you build your own groupings of tests and treat each grouping as a single runnable unit.
This is different from the Tests tab. There, a “suite” means whatever your framework already groups together — a spec file, a describe block, a feature file. Here, a suite is something you define: a named set of tests pulled from anywhere in the project, with its own run options, its own schedule, and its own notification rules.
Why you’d use it
Section titled “Why you’d use it”- A smoke pack. Twelve tests from eight different files that together prove the app is alive. Run them before every deploy.
- A regression pack per release. Pull the tests that cover what changed, run them as one unit, and re-run only the failures.
- A nightly job that owns its own settings. A suite carries its own browser/device, extra arguments, setup and teardown — so scheduling it doesn’t depend on someone remembering the right command.
The suite list
Section titled “The suite list”The tab opens on the list of suites you’ve created. Each row shows the suite’s name, how many tests it holds, its last result, and — when a schedule is enabled — a Scheduled badge with a clock icon.
A search box across the top filters by suite name, test name, or tag, so you can find a suite by something inside it rather than only by its title.
Each row carries a Run action that executes every test in the suite using the suite’s default run options.
Inside a suite
Section titled “Inside a suite”Opening a suite shows its tests and its configuration.
The test list
Section titled “The test list”Every test in the suite appears as a row with its status, name (shown in readable form), and duration. Rows reveal extra actions on hover:
| Element | What it does |
|---|---|
| Status + name | The test’s most recent outcome in this suite, and the test itself. |
| Retry chip | When a test needed retries, a chip shows the attempt count — expand it to see each individual attempt. |
| Open run | Jumps to that test’s run in Results, with its logs, screenshots, and trace. |
| Remove | Takes the test out of this suite. It does not delete the test from your project. |
A search box filters within the suite once it holds enough tests to need one.
Running a suite
Section titled “Running a suite”| Action | What it does |
|---|---|
| Run | Executes every test in the suite using its default run options. |
| Re-run only the failed tests | Re-runs just the failures from the last execution — the fastest way to confirm a fix without paying for the whole suite again. |
Suite settings
Section titled “Suite settings”A suite’s configuration is grouped into cards:
| Card | What you set |
|---|---|
| Details | The suite’s name and an optional description. |
| Default run options | The browser or device, environment, and any extra arguments (for example -DbaseUrl=https://staging.example.com -Dbrowser=firefox) applied to every test in the suite. |
| Setup & teardown | Commands to run before and after the suite — seeding data, starting a service, cleaning up afterwards. |
| Schedule | Turn on a cron schedule so the suite runs unattended. The same cron builder used by the Schedules tab is embedded here. |
| Notifications | Whether to notify on Manual runs, Scheduled runs, or Both. |
| Channels | Where those notifications go — the destinations you configured under Connectors. |
Common Tasks (How Do I…?)
Section titled “Common Tasks (How Do I…?)”How do I create a suite?
Section titled “How do I create a suite?”Open the Suites tab and create a new suite, give it a name, then add tests to it. You can also select tests on the Tests tab and add them to a suite in bulk.
How do I add tests from several different files?
Section titled “How do I add tests from several different files?”That’s the point of a suite — add them from anywhere in the project. The suite holds references to the tests, so the files themselves stay untouched.
How do I re-run just what failed?
Section titled “How do I re-run just what failed?”Open the suite and use Re-run only the failed tests. Nothing that passed is executed again.
How do I make a suite run every night?
Section titled “How do I make a suite run every night?”Open the suite’s Schedule card, turn it on, and pick a cron expression. The suite runs with its saved default run options — no command to type.
How do I get told when it fails?
Section titled “How do I get told when it fails?”Set Notifications to Scheduled (or Both) and pick your Channels. Configure the destinations themselves under Connectors.
Where do the results go?
Section titled “Where do the results go?”To Results, like every other run. A suite run appears as one master entry; open it to reach each test’s own console output and artifacts.
Tips & Best Practices
Section titled “Tips & Best Practices”- Keep smoke suites small. A smoke pack that takes 20 minutes stops being a smoke pack. Aim for the shortest set that would catch a broken deploy.
- Put the environment in the suite, not in people’s heads. Default run options travel with the suite, so a scheduled run can’t drift from what you tested manually.
- Use “re-run only failed” during triage, then run the whole suite once at the end to confirm nothing regressed.
- Removing a test from a suite is safe — it only unlinks it. The test stays in your project and in the Tests tab.
Related
Section titled “Related”- Test Explorer overview — the screen and its two tabs.
- Tests tab — browse and run individual tests.
- Results — reading suite runs and their per-test detail.
- Schedules tab — scheduling an arbitrary run command instead.
- Connectors — configuring notification channels.