Waits & timing

Drizz supports fixed-duration waits: where to put them, how to spell them, and why element-conditioned wording is not a substitute.

Drizz supports fixed-duration waits. A wait states how long to pause, not what to wait for.

Platforms	Android · iOS
What's supported	Fixed durations only
Spellings	Wait Until 3 Seconds · Wait for 5 seconds · Wait until 10s · Wait 5s
Cost	Wait steps are not billed
Watch out	Element-conditioned wording (Wait until "Cart") is accepted by the editor but has no confirmed polling behavior

Prerequisites

• A connected device or emulator

• An open test file

Copy this

OPEN_APP com.shopease.android
Wait Until 5 Seconds

Tap on Log in
Type 9000000000 in the mobile number field
Tap on Continue
Wait Until 3 Seconds

Type 123456 in the OTP field
Tap on Verify
Wait Until 5 Seconds

Validate that the home screen is visible

Size a wait

1. Run the test and note the slowest time the screen took to appear.

2. Write Wait Until <n> Seconds with that duration, rounded up.

3. Put the wait directly after the step that triggers the navigation or network call, before the step that needs the new screen.

4. Add a Validate on the next line. Validations get up to 3 attempts, which absorbs jitter on top of the wait.

5. Re-run the test and confirm the validation passes on its first attempt.

Tap on Place Order
Wait Until 5 Seconds
Validate that Order Placed is visible

The four spellings

All four are the same command:

Spelling	Notes
Wait Until 3 Seconds	The form the editor's / palette inserts
Wait for 5 seconds	-
Wait until 10s	-
Wait 5s	-

Note: Use one spelling across a suite.

Where waits go

Position	Duration
After any tap that navigates or triggers a network call	Sized to the slowest observed run
After login, before the first validation on the landing screen	Sized to the slowest observed run
After a payment or a submission, before validating the result	Sized to the slowest observed run
After OPEN_APP	3 to 5 seconds. More for a cold start
Before a Type into a field that renders after the screen does	Sized to the field's render time

Waits are not billed. A wait costs wall-clock time in the run and nothing else.

Retries are not waits

	What it does	What it doesn't do
A wait	Pauses for a fixed duration	Nothing else — it doesn't check the screen
Validation retries	Re-checks the assertion up to 3 times in case of transition state of app	Doesn't help a Tap, Type or Scroll land on the right screen

Validation retries cover a screen that arrives a moment late. They do not cover a screen that takes four seconds — the three attempts are exhausted before the screen is ready, and the step fails.

Common mistakes

What you wrote	What happens
Wait until "Proceed to Pay" is visible	The line is accepted, but there's no confirmed polling behind it. Use a fixed wait, then validate
Wait until the dashboard loads	Same. Replace with Wait Until 5 Seconds
No wait after OPEN_APP	The first tap fires at the splash screen and resolves to nothing
No wait between a tap that navigates and the validation after it	The validation runs against the previous screen, burns all 3 attempts and fails
Wait Until 30 Seconds sprinkled through a suite	A 40-step test now takes ten minutes longer, and the real timing bug is still there
A wait longer than 10 seconds	The step before it did not complete, or the screen itself needs raising with the app team
Removing a wait because "the validation retries will handle it"	Retries cover jitter, not latency
Waiting after the validation instead of before it	The validation has already failed. Waits go before the step that needs the screen

Next

• Validate — retries, and what to assert once the screen arrives

• The shape of a test — where waits sit in the five beats

• Command index — every command in one table

---

Last updated: 6 August 2026