The shape of a test

The structure of a Drizz test: one instruction per line, five beats, and the command palette that lists everything Drizz understands.

A Drizz test is a plain text file: one instruction per line, running top to bottom.

Format	Plain text. No selectors, no page objects, no SDK
Comments	Lines starting with # are skipped
Command list	Press / on an empty line in the editor
Test shape	Setup → Navigate → Act → Validate → Clean up
Watch out	If a command isn't in the / palette, Drizz doesn't have it

Prerequisites

• Drizz desktop app installed and signed in

• A connected device or emulator

• A registered app — com.shopease.android in these examples

• A project with at least one test file

Copy this

# T04 — Search and add to cart

CALL login_module

Tap on the search icon
Wait Until 2 Seconds

Type running shoes in the search field
Tap on the first search result
Wait Until 3 Seconds

Validate that the product detail page is visible

Store the price as listed_price
Tap on Add to Cart
Wait Until 2 Seconds

Validate that Item added to cart is visible

CLEAR_APP com.shopease.android

Write a test

1. Open a test file in the desktop app.

2. Press / on an empty line to list every command Drizz supports.

3. Write one instruction per line, in the app's own wording. If the button reads Charge Now, write Charge Now.

4. Order the lines Setup → Navigate → Act → Validate → Clean up.

5. Add a Validate after each step that navigates, submits or pays.

6. End with CLEAR_APP <your_package_name> so the next test starts from first launch.

7. Run the test and confirm every step resolved in the report.

The five beats

Beat	What it does	Commands
1 · Setup	Open the app and get to a known state	CALL login_module, OPEN_APP com.shopease.android
2 · Navigate	Get to the screen under test	Tap, Scroll, Wait
3 · Act	The scenario itself	Tap, Type, MAP_ACTION
4 · Validate	Assert the outcome	Validate
5 · Clean up	Leave the device ready for the next test	CLEAR_APP com.shopease.android

One scenario per test.

Writing the lines

Rule	Detail
Plain English, in the app's own words	Use the exact wording on screen. Tap on Charge Now
Continuous mode	Drag and select the lines if you only plan to run those over particular screens. Note: Continuous mode works for the current state of UI
The / palette is the authoritative list	It shows every supported command, with autocomplete for package names, modules and variables. The same list is on the Command index
Repeated setup belongs in a module	Login, choosing a city, setting an address — write it once and CALL it. See Modules
Popups that can appear anywhere belong in Memory	Not in every test. See Memory & blockers
Comments start with # Eg. Tap on Proceed to Pay # Tap on Apply Coupon	Use them to label sections and to park a step that shouldn't run yet

Common mistakes

What you wrote	What happens
A test that covers login, search and checkout	One failure blocks three scenarios, and the report can't tell you which one is actually broken
No CLEAR_APP at the end	The next test starts on whatever screen this one left behind, and passes or fails for unrelated reasons
Tap on the payment button when the button reads Charge Now	Vision AI has to guess which control you meant. Wrong element, or a step that fails intermittently. Use double quotes to perform actions on spefic UI element
A command copied from an old script that isn't in the / palette	The line is classified as something else, or fails at run time. The palette is the source of truth
The same login steps pasted into 30 tests	A UI change to login breaks 30 tests instead of one module
An IF block for a promo popup, repeated in every test	The popup still interrupts the tests you forgot. Put it in Memory once

Next

• Command index — every command, one table

• Tap — the most-used command

• Waits & timing — fixed waits and where they go

---

Last updated: 6 August 2026