> 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/tap/validate.md). # Validate `Validate` asserts a condition on screen. A test passes or fails on its validations; every other command exists to reach the screen. | | | | ------------- | ----------------------------------------------------------------------------- | | **Platforms** | Android · iOS | | **Keywords** | `Validate`, `Verify`, `Confirm`, `Check` — any case | | **Retries** | Up to 3 attempts before the step fails | | **Batching** | Several checks on one line are evaluated together, in one pass | | **Watch out** | Retries are not a wait. A screen that reliably takes 4 seconds needs a `Wait` | ## Prerequisites * A connected device or emulator * An open test file * The screen under assertion reached by the steps above the `Validate` * For variable comparisons: a value captured with `SET`, or an API step ## Copy this ``` OPEN_APP com.shopease.android Wait Until 5 Seconds Tap on the cart icon Wait Until 3 Seconds Validate 1. Order Summary 2. Delivery address 3. Total amount is visible Validate that the Place Order button is enabled Validate that the error message is not visible ``` ## Write a validation 1. Add a `Wait` after the step that navigates to the screen. 2. Write `Validate is visible`, using the label exactly as it renders. 3. Add a section, a position, or a neighbor when the label appears more than once on the screen. 4. Number the checks on one line when several apply to the same screen. 5. Run the test and confirm the report lists each sub-check with its own result. ## Assertion forms

Form	Syntax	Example
Presence	`Validate <label> is visible`	`Validate Order Placed tag is visible`
Absence	`Validate <label> is not visible`	`Validate that the error message is not visible`
State	`Validate <label> is enabled` / `is disabled`	`Validate that the Place Order button is enabled`
Styling	`Validate <label> is <state> with <style>`	`Validate that the Submit button is disabled with grey colour`
Position	`Validate the <ordinal> "<label>"`	`Validate the first "Add" CTA`
Context	`Validate <label> in <section>`	`Validate Active tag is visible in subscription section`
Comparison	`Validate <a> is greater than <b>`	`Validate that the item count is greater than 0`
Arithmetic	`Validate <a> equals <expression>`	`Validate that final amount equals subtotal + tax + delivery charges`
Against a variable	`Validate <thing on screen> matches {{var}}`	`Validate that the total shown on screen matches {{order.total_amount}}`
Partial text	`Validate text starts with "<text>"` / `contains "<text>"`	`Validate text contains "Success"`
Batched	`Validate 1. <a> 2. <b> 3. <c> is visible`	`Validate 1. Order ID 2. Delivery address 3. Total amount is visible`

## Presence Use the full visible label. ``` Validate Home is visible Validate Order Placed tag is visible Validate Login CTA is visible Validate that the Customer Name is displayed Validate that the error message is not visible ``` Add context when the label appears more than once: ``` Validate Active tag is visible in subscription section Validate Apply CTA is enabled in the coupon area Validate Address is present under Profile Validate In Stock tag near product title Validate ₹499 next to MRP is present ``` Add position when identical labels repeat: ``` Validate the first "Add" CTA Validate the last "Remove" CTA Validate "Delivered" tag is visible in order history list ``` ## Several things at once Number the checks on one line. Drizz evaluates checks on the same screen in a single pass, which costs less than three separate validations. ``` Validate 1. Order ID 2. Delivery address 3. Total amount is visible Validate 1. Booking confirmed header 2. Pickup and drop location is visible Validate 1. Book an ambulance is visible 2. Bottom confirmation sheet is not visible ``` {% hint style="warning" %} If a batched validation reports false while every sub-check reads true, split it across two lines. {% endhint %} ## Styling and state ``` Validate that the Submit button is disabled with grey colour Validate that the selected tab is highlighted with a white outline around it Validate cancel CTA is disabled beside Apply coupon of first coupon Validate "Select" is enabled in delivery options ``` ## Numbers and comparisons Drizz evaluates arithmetic rather than reading the total off the screen. ``` Validate that the item count is greater than 0 Validate that total equals sum of item prices Validate that discount equals 10% of subtotal Validate that final amount equals subtotal + tax + delivery charges Validate that payable amount equals total - discount Validate that line item amount equals unit price multiplied by quantity ``` Group calculations that belong together onto one line so they're evaluated as a set: ``` Validate the following calculations: 1. Subtotal+Tax=Total 2. Total-Discount=Final Amount ``` Directional checks (`greater than`) survive a pricing change. A hard-coded expected total does not. ## Against a variable or an API response Compare what's on screen to a value captured earlier or pulled from an API. ``` Validate that the total shown on screen matches {{order.total_amount}} Validate {{memberDetails.fullname}} is visible on the screen Validate vehicle name shown on screen matches selected_vehicle_api.make_model Validate 1. File a claim is visible on screen 2. selected_vehicle_api.policy_count is greater than 0 ``` See [Store & SET](/writing-tests/which-variable/store-and-set.md) for capturing the values, and [API steps](/writing-tests/api-steps.md) for pulling them from an API. ## Inside a conditional ``` IF While using the app CTA is visible { Tap on While using the app CTA } ``` ## Dynamic text When only part of the label is stable, validate the stable part. ``` Validate text starts with "Order" Validate text contains "Success" ``` Full-text validation applies everywhere else. Partial matches over-match. ## Retries A validation gets up to **3 attempts** before it fails. Retries absorb jitter, not latency. A screen that reliably takes four seconds needs `Wait Until 4 Seconds` — by the time three attempts are exhausted, the step has failed on a screen that was never ready. See [Waits & timing](/writing-tests/waits-and-timing.md). ## Redundant validations A `Scroll ... until "FAQs" is visible` that succeeded has already put the element on screen. A `Validate FAQs is visible` on the next line is a duplicate check that costs a pass over the screen. ## Common mistakes

What you wrote	What happens
`Validate Placed is visible` when the label reads `Order Placed`	A partial match can hit the wrong element. Validate the full label
`Validate Apply is visible` on a screen with three coupons	Matches whichever one it finds first. Add the section or a position
A `Validate` immediately after a tap that navigates	The validation runs against the old screen, burns its 3 attempts and fails. Add a `Wait`
`Validate that total is 1499` with server-driven pricing	Passes today, fails the next time pricing changes. Use `greater than` or compare against a stored value
Validating a variable's name — `Validate phone is visible`	Checks for the literal text "phone". Validate the value, or the label it sits under
Three separate `Validate` lines for one screen	Three passes over the same screen. Number them on one line instead
A test that taps through five screens and validates nothing	Passes even when the app is broken

## Next * [Waits & timing](/writing-tests/waits-and-timing.md) — the fix for validations that fail on slow screens * [Conditionals](/writing-tests/conditionals.md) — `IF Validate` blocks * [Store & SET](/writing-tests/which-variable/store-and-set.md) — capturing values to validate against *** *Last updated: 6 August 2026*