As your library of UI tests grows, how you organise them becomes important. In Automated Testing, folders keep things tidy and decide what a test job runs. When you set up a test job, you can choose to run all tests or a selection of folders.
This guide walks through the folder structure we recommend for most teams, along with some tips for keeping individual tests easy to maintain. Every team is different, so adapt it to suit yours.
Arrange tests by frequency and function
Test jobs run multiple tests at once, either manually, on a schedule, or from a pipeline when changes are merged.
A test job runs all the tests in a folder and its sub-folders. One option is to group tests by how often they run. For example, you might have folders for Daily, Weekly and Monthly tests. To avoid copying a test into more than one folder, nest your frequency folders: put Daily inside Weekly, and Weekly inside Monthly. A Weekly job then runs the Daily tests too, so each test only needs to live in the folder for the most frequent run it belongs to.
Within these folders, you can also have further sub-folders to organise by function, such as by process or workflow. For example, tests related to sales processes can be grouped together.
Working across several teams? If different teams own their own test jobs, for example Sales Cloud and Service Cloud, make the team your top-level folder.
Best practices
A good folder tree only works if each test can run on its own, in any job, in any order.
Test one outcome per test. "Quote over 20% discount goes to approval" is a test; "everything in CPQ" is not.
Name tests clearly so results are easy to interpret. A pattern like Process, Persona, Outcome works well.
Keep drafts separate. All tests in a folder run with the job, so store unfinished tests elsewhere until they pass reliably. Otherwise they may fail live jobs.
Keep tests self-contained. Each test should create the records it needs. Tests run in parallel, so a test can’t rely on another running first. If it needs another test’s steps, add that test as a reusable step.
Reuse tests instead of duplicating them. Any test can be used as a building block for another test. This allows you to maintain a single source of truth, while referencing it in multiple places. See Improving test maintainability with reusable tests.
Keep building-block tests in their own folder. Unless you want them to run on their own, store tests you reuse across processes separately from your main tests.