Suites

A suite is a named group of tests that runs as a single unit. Suites are how you turn a collection of related checks into one button to press, one schedule to maintain, and one notification target to configure. Common examples include every test that touches checkout, every smoke test for a release, every test on a marketing site, and every test that should run after a particular deployment.

123

1. 1How many tests belong to the suite, and how many are currently passing.
2. 2Suite health, rolled up from its members.
3. 3The suite’s own schedule, separate from any test’s.

Creating a suite

Create a suite from the Suites page in the sidebar. Inside its settings you can add tests via a dropdown and drag them into the order you want them executed. Tests in a suite run in the order you set, which matters when one test depends on the side effects of another (for example, a test that creates a record can be ordered before a test that updates it, so the second test is guaranteed to have something to act on).

Suite settings

Suites have their own integrations, schedule, email reports, and webhook URL, configured exactly like a test's. When the suite runs, every member runs and the results aggregate into the suite's run record. The suite passes only if every test inside it passed, which makes it a strict but accurate signal: one red test and the suite is red. That strictness is the point, since "mostly green" is not the same as "shipped a release".

Environments

The General tab of suite settings has an Environments setting with No environment, Selected, and All enabled. It decides where Run now, the schedule, and the trigger URL run the suite. See Environments for how environments work.

• Each environment gets its own suite run, with its own result.
• A suite run only includes the tests enabled for that environment. Tests that are not enabled for it are left out, not failed.
• All enabled means every environment that at least one test in the suite is enabled for.
• The Run now dropdown shows the suite default first, then No environment, each environment, and All enabled, so you can override the setting for one run.

Reusing tests across suites

Tests can belong to multiple suites at once. There is no penalty for re-using a test, so you can have a "release smoke" suite that includes the five most important checks across multiple feature areas, and feature-specific suites that run those same checks at a different cadence. Editing a test affects every suite that uses it, which is usually exactly what you want, since the test definition stays canonical.

Deleting a suite

Deleting a suite only removes the grouping. The tests themselves are untouched and continue to run on whatever schedules and triggers they have. That makes suites a low-cost organisational tool: you can spin one up for a release-readiness check, use it for a sprint, and remove it later without losing any history or breaking anything else.