Authoring rules
The rule list for writing Drizz tests — what to do and what to avoid, with the reason each rule exists.
The rules that apply to every Drizz test, in two tables.
Platforms
Android · iOS
Structure
Setup → navigate → act → validate → clean up
Wording
Use the app's exact visible text, always
Timing
Fixed waits only, placed after navigation and network calls
Watch out
CLEAR_APP is effectively a no-op on iOS — don't rely on it for clean state
Prerequisites
Drizz desktop app installed and signed in
A registered app and a project to hold the tests
Do
One scenario per test, ending in CLEAR_APP
A failure names one feature, and the next test starts from a known state
Copy the app's exact visible wording
Paraphrasing is the most common cause of a tap landing on the wrong element
Disambiguate, don't describe
Drizz picks one element out of everything on screen. A label, a position in a list, a neighbor or a section narrows it to one
Add a wait after anything that navigates or calls the network
Validations retry a few times, which covers a slightly slow screen, not a four-second one
Set a variable before comparing it
A number hardcoded last quarter fails when the price changes
Validate directionally — greater than, less than
Survives price and tax changes; an exact computed total does not
Validate after anything non-deterministic
Scroll stops silently at its attempt limit, so the validation is what catches the miss. Applies after MAP_ACTION, after a load-bearing SET, and after a scroll
Put anywhere-popups in Memory
One rule replaces the same IF block in forty tests
Put flow-specific popups in IF blocks
An org-wide rule makes every test in the organization pay for a check only one flow needs
Put anything repeated into a module
A login flow that changes twice a year exists in one place
Quote scroll targets and give a direction
An unquoted target with no direction doesn't resolve
Use Tap whenever the element has a visible label
MAP_ACTION is the least deterministic command in Drizz
Validate a variable's value — {{order_id}}
order_id without braces is searched for as literal on-screen text
Store only what's rendered on screen
Vision AI reads pixels. System timestamps and internal IDs aren't visible to it
Reset state explicitly on iOS — log out, or reinstall
CLEAR_APP is effectively a no-op on iOS
Use Tap on the back button for cross-platform back
PRESS_DEVICE_BACK_BUTTON doesn't exist on iOS
Pick one style per value — {{phone}}
<phone> is inert text. Drizz types the literal characters
Bind a dataset to any plan whose tests use variables
A plan with variables and no test data bound can misread SET steps
Name variables for the moment — total_before
Reusing a name overwrites the first capture permanently
Put environment and account values in a dataset
One script covers staging and production
Work the healed-steps list as a maintenance queue
A step that heals every run has a bad description
Delete tests that no longer mean anything
A green suite nobody trusts is worse than a smaller one people do
Don't
Chain three scenarios into one long test
A failure doesn't say which feature broke
Paraphrase — "Proceed to Pay" for a button that says "Charge Now"
The tap lands on the wrong element or nothing at all
Scatter long waits everywhere as insurance
Hides real timing problems and slows the whole suite
Compare against a number hardcoded last quarter
Breaks on the next price or tax change
Compute an exact expected total by hand
Same failure, one release later
Copy the same IF popup block into forty tests
Forty edits when the popup changes
Add an org-wide blocker rule for a popup only you see
Every test in the organization pays for it
Copy-paste the login flow into every test
Every test changes when login changes
Write Scroll until Proceed with no quotes and no direction
The target doesn't resolve
Trust a grid-cell gesture without validating after it
MAP_ACTION can hit the wrong thing and still report success
Reach for MAP_ACTION the first time a tap misses
Fix the description instead
Validate a variable's name — order_id as visible text
Drizz searches the screen for that literal string
Store a system timestamp or an internal ID
Not rendered, so nothing to read
Rely on CLEAR_APP for clean state on iOS
State carries over to the next test
Use PRESS_DEVICE_BACK_BUTTON in a script that runs on iOS
The command doesn't exist there
Mix {{phone}} and <phone> for the same value
One resolves, the other is typed literally
Run a plan with variables and no test data bound
SET steps can be misread
Reuse one variable name for two captures
The second write destroys the first
The shape that works
Five beats, in order:
Setup — get to a known state, with a
CALLto a shared login module.Navigate — reach the screen under test.
Act — the scenario itself.
Validate — assert the outcome.
Clean up —
CLEAR_APPso the next test starts fresh.
Common mistakes
Tap on the button
Ambiguous. Resolves differently between runs
Wait until the page loads
Not a fixed duration. Write Wait Until 5 Seconds
Scroll until Proceed
No quotes, no direction. Quote the target and say down
One test covering login, search, cart and checkout
When it fails you don't know which feature broke
CLEAR_APP as your iOS teardown
Does effectively nothing on iOS. State carries over
PRESS_DEVICE_BACK_BUTTON in a cross-platform test
Doesn't exist on iOS
A 20-second wait to fix a flaky step
Hides a real timing problem and slows the whole suite
MAP_ACTION on an element that has a label
The least deterministic command in Drizz, used for no reason
Next
Last updated: 6 August 2026
Last updated
Was this helpful?