# 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. --- # Agent Instructions: 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: ``` GET https://docs.drizz.dev/getting-started/overview/drizz-usage-expectations-and-operational-guidelines.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.