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 "[email protected]" into email field
Validate "Welcome" is presentIncorrect:
Tap login and then type email2. 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. 3.2 They cannot include additional words, optional phrasing, or chained actions. 3.3 Only one System Command is allowed per line.
Examples:
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:
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:
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:
Correct:
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:
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:
Correct Command:
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:
Correct:
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:
14.2. Incorrect Usage
14.2.1 Incorrect: Multiple Validate Commands on Separate Lines
Reason: Drizz treats these as separate evaluations, causing flakiness and inconsistent results.
14.2.2 Incorrect: Multi-Line Numbered Formatting
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.
Last updated
Was this helpful?