> For the complete documentation index, see [llms.txt](https://docs.mozark.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mozark.ai/no-code-studio/authoring-tests/recording-tests.md). # Recording tests How steps get into a test case: the right-click menu, the keyword catalogue, and what to do when the default locator is not quite right. **Prerequisites:** an app uploaded and a device session started. See [Author your first test](https://docs.mozark.ai/no-code-studio/getting-started/author-your-first-test). ## The workspace Starting a session opens the Workspace:
* **Left: the device screenshot.** A live screenshot of the real device. It is interactive: tap and type on it exactly as if you were holding it. * **Right: the authoring panel.** The **Step Builder** holds your recorded steps. The **⋯ menu above it opens Elements** (a searchable list of everything on the current screen) and **Page Source** (the raw UI tree). ## Recording a step Right-click any element on the device screenshot. The strip along the top of the menu shows the element you are pointing at (its visible text, or its XPath when it has no text) so you can confirm you grabbed the right thing before choosing an action. The menu has two levels: * **Popular**: the three commands that cover most of what a test does: **Press Element**, **Enter Text**, **Assert Presence**. * **All Commands**: hover or click to open the full catalogue beside it, with a search box and everything grouped by category. Pick a command and the step lands in the Step Builder with the element's locator already filled in.
{% hint style="info" %} **Press Element runs immediately when you record it.** The tap you just authored happens on the real device there and then, so the device screenshot stays in step with your test. Every other command is recorded without being executed; play it back yourself when you are ready. {% endhint %} ### Tools At the bottom of the **All Commands** panel is a **Tools** section for things that are not test steps: | Tool | What it does | | --------------------------- | ---------------------------------------------------------------------------------------------------- | | Extract value into variable | Reads the text off this element at run time and stores it in a `${variable}` for a later step to use | | Copy XPath | Copies the element's locator to your clipboard | ### Adding a step without an element Not every step acts on something you can point at: *Sleep*, *Launch other app*, *Enter Text Direct*. Use **Add → Step** in the Step Builder header and pick the keyword from the list. Locator parameters are left empty for you to fill in.
## Locators and fallbacks When you right-click an element, App Studio records more than one way to find it: ``` Primary //android.widget.EditText[@resource-id="et_search"] Fallback //*[@content-desc="Search movies"] Fallback Search movies ``` At run time the engine tries each candidate in order. Each candidate also cascades through the matching strategies: XPath, then visible text, then OCR. This is why a recorded test tends to survive a redesign that would break a hand-written selector, and why the same test usually runs unchanged on devices whose XPaths differ. If a step still cannot find its element, see [Troubleshooting](https://docs.mozark.ai/no-code-studio/reference/troubleshooting). ### Search-area parameters Most element keywords carry four extra parameters, **Search area X, Y, width, height**. They are percentages of the screen and default to `0, 0, 100, 100` (the whole screen). Narrow them when the same text appears more than once and you only care about one region. To match only in the bottom half of the screen: ``` Search area X 0 Search area Y 50 Search area width 100 Search area height 50 ``` Leave them at the defaults unless you have a reason. ## Working with recorded steps | Action | How | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | Reorder | Drag a step by its handle | | Edit a parameter | Click the field on the step card and type | | Play everything | **Run all** in the Step Builder header | | Stop a run | **Stop**, which replaces Run all while it is running | | Play from one step | Step overflow menu → **Run from here** | | Delete | Step overflow menu → **Remove step** | | Insert a variable | Focus a field, then click `{x}` at the top of the step list | | Insert a data-set column | Focus a field, then click the data-set button. See [Test data](https://docs.mozark.ai/no-code-studio/authoring-tests/test-data) | Use **Run from here** while you iterate. It saves replaying a long login every time you adjust the last step. ## Stopping and naming Click **Stop** when you are done. It saves the steps, releases the device, and opens the recording on the **Test Cases** screen, where it carries a placeholder name such as `Unsaved recording · Pixel 7 · 26 Aug, 15:42`. Type a real name and click **Save**. To carry on editing an existing test on a device later, open it from **Test Cases** and start a session from there. ## Capturing a value from the screen Some tests need a value the app generates: an OTP, an order number, a balance. 1. Right-click the element showing the value. 2. **All Commands → Tools → Extract value into variable**. 3. Give it a name, for example `order_id`. App Studio records a **Get Text** step that reads the element and stores the result in `${order_id}`. Any later step can use it: ``` Get Text "#ORD-99341" → ${order_id} Press Element "Track order" Enter Text ${order_id} Assert Presence Tracking ${order_id} ``` Variable names must start with a letter or underscore and contain only letters, digits and underscores. `order_id` is valid; `2nd-order` is not. The variable appears on the **Variables** screen with source **Runtime**, meaning its value only exists while the test is running. {% hint style="warning" %} **Order matters.** A runtime variable is only available to steps that come after the step that captured it. Using it earlier is a scope error, flagged with an amber badge on the step. {% endhint %} ## The Elements screen **Elements** is a named-locator reference library for the project. Each entry has a name and a set of per-platform locator candidates. It is useful as documentation of the locators your app uses, and it is populated automatically when you [import an existing Optics script](https://docs.mozark.ai/no-code-studio/authoring-tests/importing-an-existing-script). {% hint style="info" %} Recorded steps carry their own locators. A step you record in the workspace stores its XPath and fallbacks directly on the step; it does not point at an Elements entry. Editing an Elements row does not change steps you have already recorded. Treat this screen as a reference library, not as a central place to re-point existing tests. {% endhint %} ## Keywords Around 50 keywords are available. The ones you will actually use are listed in the [Keyword reference](https://docs.mozark.ai/no-code-studio/reference/keyword-reference). ## Next * [Modules](https://docs.mozark.ai/no-code-studio/authoring-tests/modules): stop recording your login flow over and over. * [Test data](https://docs.mozark.ai/no-code-studio/authoring-tests/test-data): one test, different data per device. * [Conditions](https://docs.mozark.ai/no-code-studio/authoring-tests/conditions): branching for flows that vary. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.mozark.ai/no-code-studio/authoring-tests/recording-tests.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.