Composite Test Suites

A composite test suite is a suite that contains other suites. Run a composite and it runs each child suite in sequence. Useful for stitching short focused suites into larger reporting groups without rewriting them.

When to use composite suites

Scenario	Why composite makes sense
Several teams own different parts of one user journey	Each team owns a focused suite; the composite stitches them so you have one CI signal for the whole journey.
You have a smoke suite + a feature suite + an accessibility suite	Run all three from one schedule without making one giant suite that's hard to maintain.
You want a "release readiness" suite	Combine the most critical suites into one composite. Run before every release.
Critical-path collection	Group your most important suites into a "release readiness" composite, run on every PR.

Creating a composite suite

1. From the Test Suites page, click + New Suite → Composite.
2. Name it (e.g. "Release smoke", "Full user journey").
3. Click + Add child and pick suites from the list. Order matters — they run top to bottom.
4. Save.

Anatomy of a composite

A composite has:

• Children — ordered list of regular suites (or other composites).
• Shared project environment — tokens, cookies, headers, login script come from the project, the same as for any single suite.

Each child suite executes top-to-bottom in the order you arranged. If a child fails, the composite is marked failed; subsequent children still run so you see the full picture.

Running a composite

Same as a regular suite — click Run, pick browsers, watch results. The run page groups children:

• Top-level pass/fail count is the union of all children.
• Each child suite is its own collapsible section.
• Click into any child to see its individual test cases.

Scheduling a composite

Composites work in schedules just like regular suites. Common pattern: a "nightly" composite that runs every critical suite, scheduled at midnight on weekdays.

Composite of composites

Composites can contain other composites — useful for nesting. Example:

• Smoke — 3 small auth/critical-path suites.
• Feature — 5 feature-area suites.
• Release readiness — composite containing Smoke + Feature.

Schedule each composite separately depending on cadence: smoke hourly, feature daily, release-readiness on PRs.

Editing a composite

• Reorder children by drag-and-drop.
• Remove a child with the trash icon. Doesn't delete the underlying suite — just removes from this composite.
• Toggle a child off temporarily without removing.
• Tag children with their own labels (e.g. "slow", "smoke", "owner-team-x").

Plan availability

Plan	Composite suites per project
Free	—
Starter	1
Pro	10
Business / Enterprise	Unlimited

Common questions

Can a composite include suites from different projects?

No — composites are project-scoped. If you need cross-project orchestration, use the API to trigger multiple project runs from a single CI step.

What happens to test data between children?

Each child runs against the project's environment — same tokens, cookies, headers, login script. Each child runs in its own browser context and starts fresh, so there's no implicit state passed between them.

Can I retry just one failed child suite?

Open the run, find the child, click Re-run this suite. The retry runs in isolation — it doesn't re-run the rest of the composite.

Related

• User Flow Tests — for in-suite multi-step journeys.
• Scheduling Tests
• Running Tests