> For the complete documentation index, see [llms.txt](https://docs.drizz.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.drizz.dev/getting-started/overview/drizz-usage-expectations-and-operational-guidelines.md). # Drizz Usage Expectations & Operational Guidelines This section outlines the **core rules**, **constraints**, and **best-practice principles** required to author stable, deterministic, and enterprise-ready automated test flows using Drizz.\ Adhering to these guidelines ensures maximum reliability across Android, iOS, and M-Web executions. ## **1. Use One Command Per Line** 1.1 Drizz processes **exactly one action per line**.\ 1.2 Multi-action or conversational lines are not supported.\ 1.3 Each command must be written as a single, atomic instruction. **Correct:** ``` Tap on "Login" Type "john@example.com" into email field Validate "Welcome" is present ``` **Incorrect:** ``` Tap login and then type email ``` ## **2. Provide Explicit Context to Improve Reliability** 2.1 Always describe *what* to interact with and *where it belongs*.\ 2.2 Use surrounding UI context (headers, sections, placeholders, positions).\ 2.3 The richer the context, the higher the accuracy. **Examples:** * Tap on "Add to Cart" under "Electronics" * Type "John" into "First Name" * Validate the following are present: 1. "Price" 2. "Discount" 3. "Total Amount" * Scroll down inside the product list ## **3. Follow Strict Syntax for System Commands** 3.1 System Commands must be used [exactly as defined](https://drizz.gitbook.io/docs.drizz.dev/~/revisions/ACoww6nTi8acCw4g2ai5/commands-reference/4.2-system-command).\ 3.2 They cannot include additional words, optional phrasing, or chained actions.\ 3.3 Only one System Command is allowed per line. **Examples:** ``` OPEN_APP:com.android.chrome KILL_APP MINIMISE_APP CLEAR_APP PRESS_DEVICE_BACK_BUTTON SET_GPS(latitude=12.9716, longitude=77.5946) ``` 3.4 Any deviation from the exact syntax will cause failure. ## **4. Be Precise With MAP\_ACTION Commands** 4.1 Use MAP\_ACTION only when UI detection cannot be used (maps, sliders, overlays).\ 4.2 Always specify **direction** and **intent** clearly.\ 4.3 Avoid vague gestures. **Example:** ``` MAP_ACTION Drag red pointer from left to right on slider ``` 4.4 MAP\_ACTION must not reference UI text—it works on surfaces, not elements. ## **5. Scroll & Scroll Until “X” Must Be Unambiguous** ### **5.1 Scroll Commands** 5.1.1 Direction is mandatory (up, down, left, right).\ 5.1.2 Default scroll distance = **50%** unless specified. ### **5.2 Scroll Until “X”** 5.2.1 Target text must be enclosed in **double quotes**.\ 5.2.2 Intent must be explicit.\ 5.2.3 Container-level context must be provided when multiple scroll views exist. **Examples:** ``` Scroll down until "Apply Coupon" Scroll right until "More Categories" Scroll down until you find 4 product cards under "Beauty" ``` 5.3 Ambiguous target definitions reduce reliability—be highly specific. ## **6. Ensure Proper Device Connectivity** ### **6.1 Android Devices** 6.1.1 Install Android Studio.\ 6.1.2 Ensure ADB is configured correctly.\ 6.1.3 Grant necessary permissions. ### **6.2 iOS Devices** 6.2.1 Install Xcode.\ 6.2.3 Trust the Mac on the device. ## **7. App Connection Must Be Stable Before Execution** 7.1 The App Under Test (AUT) must be installed and launchable.\ 7.2 Handle onboarding screens, permissions etc before deeper flows.\ 7.3 Drizz executes only on the **currently rendered UI**. ## **8. Avoid Ambiguous or Generalized Commands** 8.1 Commands must never rely on vague descriptions like “it”, “that button”, or “scroll a bit”.\ 8.2 Strong references ensure predictable execution. **Incorrect:** ``` Tap on the button Scroll until you see it Type number ``` **Correct:** ``` Tap on "Continue" CTA Scroll down until "Address Details" under view address header Type "9999999999" into "Phone Number" ``` ## **9. Use Unique Memory Variable Names** 9.1 Memory overwrites occur when the same variable name is used multiple times.\ 9.2 Always assign **distinct, descriptive names**. **Example:** * otp\_login * otp\_payment * promo\_code * referral\_token 9.3 Overwriting memory unintentionally leads to loss of original context. ## **10. Write Clear Conditional Blocks** 10.1 Blocks must include at least **IF + ELSE**.\ 10.2 Use braces `{ }` for structure.\ 10.3 Keep conditions simple and readable. **Example:** ``` IF profile icon is visible { Tap on "Profile" } ELSE IF hamburger menu is visible { Tap on "Menu" } ELSE { Validate "Navigation element missing" } ``` 10.4 Conditions must be based on visible UI elements only. ## **11. Commands Must Match Visible UI Exactly** 11.1 Text must match **exactly** what is shown on the screen.\ 11.2 Avoid synonyms, abbreviations, or paraphrases. **UI Text:** ``` Continue as Guest ``` **Correct Command:** ``` Tap on "Continue as Guest" ``` ## **12. Drizz Only Interacts With Visible UI** 12.1 Hidden or off-screen elements cannot be tapped.\ 12.2 Always scroll before attempting interaction.\ 12.3 Minimized app states require reopening with OPEN\_APP. ## **13. Avoid High-Level Narrative Instructions** 13.1 Drizz does not support multi-step paragraphs.\ 13.2 Break down actions into explicit commands. **Incorrect:** ``` Scroll a little and then tap login when it shows up. ``` **Correct:** ``` Scroll down until "Login" CTA Tap on "Login" ``` ## **14. Multiple Validation :** **Correct and Incorrect Usage** Drizz supports multiple validations in a single command, provided the syntax is precise, numbered, and written on one line. ### **14.1 Correct Usage** 1.1 Always write multiple validations in a **single continuous line**.\ 1.2 Each validation item must be **numbered** (1., 2., 3., …).\ 1.3 A clear visibility intent (e.g., *are visible*, *are present*) must be included. **Correct Format:** ``` Validate the following are visible: 1. "Price" 2. "Discount" 3. "Total Amount" ``` ### **14.2. Incorrect Usage** #### **14.2.1 Incorrect: Multiple Validate Commands on Separate Lines** ``` Validate- "Price" is visible and validate "Discount" is visible ``` Reason: Drizz treats these as separate evaluations, causing flakiness and inconsistent results. #### **14.2.2 Incorrect: Multi-Line Numbered Formatting** ``` Validate - 1. "Price" 2. "Discount" 3. "Total Amount" is visible ``` Reason: Drizz does not support multi-line commands or broken syntax structures. ## **15. Keep Tests Deterministic** 15.1 Avoid reliance on unstable network timing.\ 15.2 Add validations to anchor critical transitions.\ 15.3 Handle dynamic screens explicitly.\ 15.4 Never assume an element will always appear, validate it.