> For the complete documentation index, see [llms.txt](https://docs.bugbug.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bugbug.io/organizing-tests/suites.md). # Suites ### Why use suites? Suites are great for grouping test cases to run them in parallel. They are simply groups of multiple tests. Organise your tests into Suites to quickly **run several tests at once**. By default BugBug has one suite called "All tests", where you will find all tests you created in a project. All newly created tests will be automatically added to this suite. Suites can be [scheduled](/running-tests/schedules.md) to run in the cloud and are useful for [working with different environments](/editing-tests/variables.md#work-with-different-development-environments). ### What suites should I have? Here are some examples of suites that usually help with test automation workflow. * you can have a suite that monitors only core features on your production, [scheduled](/running-tests/schedules.md) every hour * you can have a full regression suite that you run manually before the release * you can have a "feature branch" suite that has work in progress tests that are not yet ready to be run on production, but after the release you will add them to the production suite * you can have suites that run the same tests with different [profiles](/editing-tests/variables.md#profiles), for example checking your app on multiple languages
### Create new custom suite You can create custom suites in the Suites tab: 1. Click `Create new suite` button 2. Add `Suite name` 3. Choose tests that you want to include in a suite 4. Choose options for a suite 5. Save
### Auto-retry failed cloud tests to prevent flaky tests notifications If your suite sometimes randomly fails, but there is no certain reason for that, you may be annoyed by the "failed" false positive [notifications](/collaboration/alerts.md). The industry term for tests that fail randomly for no reason is *flaky tests*. *Flakiness* can be caused by many different factors: * a slowdown in the internet connection * busy server side * temporary machine CPU overload You probably don't want to get notifications for such randomly failed tests - your app works as it should, it was just a temporary problem that doesn't require attention. BugBug allows you to prevent such unnecessary alerts.
**When auto-retry is enabled:** * If one of the tests in a suite fails, it will be automatically run again * if another attempt passes, we will mark the suite as "passed", but you can still see the failed test attempt in the [test runs history](/debugging-tests/runs-history.md), marked as "auto-retried" * If the test fails for the second time, it will be again restarted * If the test fails the specified number of times, we will mark the suite as "failed"

Example suite run history with auto-retry enabled. There were 3 attempts to run the same test.

**When auto-retry is disabled:** * If any of the tests fail, the suite will continue running and after all the tests are finished it will be marked as "failed"

Example suite run history with auto-retry disabled. There was just one attempt to run the test.

{% hint style="info" %} **Important!** Auto-retry only works in suites run in the BugBug cloud. [Pro subscription](https://bugbug.io/pricing) is required. {% endhint %} ### Before all / After all tests Some tests should always run first, as setup, or always run last, as cleanup. The Before all and After all sections let you assign existing tests to these roles (for example, logging in before the rest of the suite runs, or clearing test data once it's done). This doesn't add a new kind of test. You still create and edit tests the normal way; Before all and After all just mark where in the suite an existing test runs. **Enable Before all / After all** Before all and After all are off by default for every suite. To turn them on: 1. Open the suite and go to its options 2. Enable the `Before all / After all` option 3. Save

Enable Before all / After all in the suite options.

Once enabled, the suite's edit view shows three sections instead of one list: Before all, Main suite tests, and After all. Add each test to the section it belongs to.

A suite with Before all and After all enabled, showing all three sections.

{% hint style="warning" %} Dragging and dropping still reorders tests within a section. It doesn't move a test between sections (Before all, Main suite tests, After all). {% endhint %} **How Before all / After all tests run** Tests in Before all and After all always run sequentially, one after another, regardless of whether the suite's main tests run in parallel. * Before all tests run first. If one of them finishes "failed" or "error", the suite run stops there: the suite is marked "failed"/"error", and everything that hasn't run yet, the rest of Before all, the main suite tests, and After all, is marked "skipped". * If Before all finishes without a failure, the main suite tests run as usual. * After all tests always run once the main suite tests are done, even if one or more of them failed. * If an After all test finishes "failed" or "error", the suite is marked "failed"/"error", and any After all tests that hadn't run yet are marked "skipped". **Before all / After all via API and YAML** The [Public API](/integrations/public-api.md) can read and update a suite's Before all/After all tests, and the [YAML schema](/export-import-and-backup/yaml-schema.md) covers how they're represented on export and import. **In reports** Tests from Before all and After all show up in suite run reports and [runs history](/debugging-tests/runs-history.md) like any other test. There's no separate section for them. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.bugbug.io/organizing-tests/suites.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.