Structuring the object repository for autotests ​

Recommendation on how to keep the object repository so ComplexQA autotest steps reuse paths and locators without copying them.

Why ​

One control in ten autotests with different locator strings breaks in ten places at once. A catalog page and element give a single edit point and a stable Target for steps.

How to work ​

1. Create a page for a stable screen path (kind PAGE). Store a screen on the same host as the run starting domain as a relative path. Store a screen on a team subdomain (after a click inside COMMON) as a full https://{slug}.host/… URL. A verified root covers its subdomains. A relative goto always joins the starting domain of the run, not the current tab.
2. Group pages and elements in folders that match screens or areas of the product. Drag a row onto a folder in the tree, including onto an empty folder. At the tree root the table lists every record in the project; open a folder to narrow the list.
3. Create elements for that page's controls (kind ELEMENT) with an unambiguous locator: prefer TESTID, ROLE, LABEL.
4. Name records so a step author finds them without guessing (screen + control role).
5. In steps, pick the catalog element or page instead of an on-step locator when Target repeats. Flow: Binding a Target from the object repository.
6. Draft steps from a catalog page: Autotest generation from a page.
7. After product markup changes, fix the locator on the catalog element, then re-run the affected CASE items.

What to avoid ​

The repository does not run tests. Execution happens in an autotest run.