> For the complete documentation index, see [llms.txt](https://docs.drizz.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.drizz.dev/writing-tests/conditionals.md). # Conditionals `IF` blocks run steps only when a condition holds on screen. One script covers apps that show different screens to different users. | | | | --------------- | --------------------------------------------------------------------------- | | **Platforms** | Android · iOS | | **Branches** | `IF` → `ELSE IF` → `ELSE` | | **Braces** | `{` and `}` each go on their own line | | **Indentation** | Required, not cosmetic | | **Watch out** | Prefix the condition with `Validate` — a bare `IF` classifies less reliably | ## Prerequisites * A connected device or emulator * An open test file * A condition that is checkable on a single screen ## Copy this ``` OPEN_APP com.shopease.android Wait Until 5 Seconds IF Validate that the location permission dialog is visible { Tap on While using the app Wait Until 2 Seconds } Tap on the search icon Type running shoes in the search field Validate that search results are visible ``` ## Write an IF block 1. Write `IF Validate ` on its own line. 2. Put the opening brace `{` on the next line, on its own. 3. Indent the body. Write one action per line. 4. Close with `}` on its own line. 5. Add `ELSE IF` and `ELSE` branches for the other states the screen can be in. 6. Confirm every branch leaves the app on the same screen, so the steps after the block work in all cases. 7. Run the test and confirm the report shows which branch was taken. ## Branches | Keyword | When it runs | Condition | | --------------------- | ----------------------------------------------- | ----------------------------------------------------- | | `IF ` | The condition holds | Required. Prefix with `Validate` for a presence check | | `ELSE IF ` | The `IF` did not match and this condition holds | Required | | `ELSE` | No earlier branch matched | None | ## Two branches ``` IF Profile icon is visible { Tap on Profile icon } ELSE { Tap on Hamburger menu } ``` ## Three or more branches ``` IF Proceed to Pay is visible { Tap on Proceed to Pay } ELSE IF Slide to pay is visible { Drag the slider from left to right } ELSE { Scroll down until "Proceed" CTA is visible Tap on Proceed } ``` ## Nesting ``` IF Validate that the Employee Attendance screen is displayed { IF Validate that the Clock In button is displayed { Tap on Clock In Wait Until 3 Seconds } Tap on Close button } ELSE { Tap on Skip } ``` ## Syntax rules

Rule	Detail
Opening brace on its own line	`{` never sits at the end of the `IF` line
Indent the body	Indentation is part of the syntax, not formatting
Prefix presence checks with `Validate`	`IF Validate that the permission dialog is visible` classifies more reliably than the bare form
One condition per branch	A condition that checks two elements is harder to evaluate, and the report can't say which half was false
Every branch stands on its own	A branch cannot depend on steps that only run in another branch
Order branches by likelihood	Most common state in the `IF`, alternatives in `ELSE IF`, the unexpected in `ELSE`
A false `IF` costs one screen check	It does not fail the step

## Popups that can appear anywhere Promotional overlays, permission prompts, "rate this app" and network retry sheets can interrupt any test at any point. They belong in the app's blocker rules in **Memory**, written once. Drizz dismisses them during any run, with no step in the script. `IF` covers state tied to one screen or one scenario: ``` IF Address Suggestion dropdown is visible { Tap on the first suggestion } IF minimum order value popup is visible { Tap on OK Wait Until 1 Seconds } ``` See [Memory & blockers](/writing-tests/memory-and-blockers.md) for the split, and for how to write a blocker rule. ## Common mistakes

What you wrote	What happens
`IF the popup is visible {` — brace on the same line	The block isn't parsed as a block
An unindented body	Same. Indentation is part of the syntax
An `IF` for the same promo popup, copied into 30 tests	The popup still interrupts the tests you forgot. One blocker rule in Memory covers all of them
A condition that checks two things at once	Harder to evaluate, and the report can't tell you which half was false
`IF` with a body that leaves the app on a different screen than the `ELSE` body does	The steps after the block work in one branch and fail in the other
No `ELSE` on a screen that has a third variation you haven't seen	The script silently does nothing and fails further down. Add a fallback
A blocker rule in Memory and an `IF` for the same popup	The rule dismisses it, then the `IF` finds nothing and the branch is skipped — noise in every report

## Next * [Memory & blockers](/writing-tests/memory-and-blockers.md) — handle anywhere-popups once * [Validate](/writing-tests/tap/validate.md) — writing the condition * [Modules](/writing-tests/modules.md) — extract a large branch into its own module *** *Last updated: 6 August 2026*