> For the complete documentation index, see [llms.txt](https://docs.mozark.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mozark.ai/no-code-studio/authoring-tests/conditions.md).

# Conditions

Real apps do not always do the same thing. A promo screen appears on first launch. A consent dialog shows in some regions. A returning user skips onboarding.

A **Condition** block branches your test so one test case handles all of it.

## Add a condition

In the Step Builder, **Add → Condition**. A new block appears with two branches:

```
IF    <condition>
        (steps)
ELSE
        (steps)
```

Record steps into a branch by selecting it as the recording target, then right-clicking on the device as usual. Steps land in the branch you targeted.

<figure><img src="https://952269762-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRBaaAIJoDzwDclOOVa8Z%2Fuploads%2FY26HF78YhGwnIqhecwIw%2F25-condition-block.png?alt=media&amp;token=d88cc0d2-60fa-43df-8a6e-cd02d9ae219c" alt=""><figcaption></figcaption></figure>

Add more paths with **ELSE IF**. Conditions can be nested inside branches.

{% hint style="info" %}
An empty branch is ignored entirely. If you add an ELSE and never put steps in it, it is simply not part of the test. Nothing breaks.
{% endhint %}

## Building the condition

Each branch runs when its condition is true. A condition is one or more **clauses**, joined by AND or OR. A clause has three parts: a **source**, an **operator**, and usually a **value** to compare against.

### Sources

| Source     | Checks                                                   | Example                            |
| ---------- | -------------------------------------------------------- | ---------------------------------- |
| Element    | Something on the screen                                  | `"Skip"` exists                    |
| Variable   | A `${variable}` value                                    | `${region}` equals `US`            |
| Expression | A raw expression, for cases the first two cannot express | `${count} > 0 and ${region}=="US"` |

For an element clause, enter the element as **visible text or an XPath**: the same thing you would see in the right-click menu header.

<figure><img src="https://952269762-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRBaaAIJoDzwDclOOVa8Z%2Fuploads%2FAevPtApJaC2e3wE5Ih0z%2F26-condition-sources.png?alt=media&amp;token=e2161749-4527-42d1-b6b9-45f69fbbaf84" alt=""><figcaption></figcaption></figure>

### Operators

**Element clauses**

| Operator       | Meaning                                   |
| -------------- | ----------------------------------------- |
| exists         | The element is on screen                  |
| is not present | The element is not on screen              |
| text equals    | The element's text exactly equals a value |
| text contains  | The element's text contains a value       |

**Variable clauses** compare a variable with a value, including whole-number comparisons (`>` and `<`).

<figure><img src="https://952269762-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRBaaAIJoDzwDclOOVa8Z%2Fuploads%2FbGCwdMUayAFpkbG4X86u%2F27-condition-operators.png?alt=media&amp;token=0e785123-3d99-4f06-ab4d-5209b89d58aa" alt=""><figcaption></figcaption></figure>

### Probe timeout

Element clauses have a **timeout**, defaulting to 5 seconds: how long to look for the element before deciding it is not there.

Keep it short. This timeout is paid on **every** run where the element is absent, so a 30-second probe on a screen that usually does not appear adds 30 seconds to every run.

## Combining clauses

Clauses can be combined, with one restriction. A condition must be either:

* all element *exists* checks joined by AND, **or**
* all variable / expression checks (AND or OR).

Mixing an element check with a variable check in one condition is not supported. App Studio tells you rather than silently mis-compiling:

> Combine only element "exists" checks with AND, or only variable/expression checks. For other mixes, use an ELSE IF branch.

To express a mix, use separate branches or nest a condition inside a branch.

## Worked example: skip an onboarding screen

Your app shows a *Get started* carousel on first launch, but not for a returning user. Without a condition you need two test cases. With one:

```
Launch and sign in                       (module)
IF   "Get started"  exists   (timeout 5s)
       Press Element  "Skip"
       Press Element  "Continue"
ELSE
       (empty - nothing to do)
Navigate to watchlist                    (module)
Assert Presence  "My list"
```

One test case, both paths, no flakiness.

## Worked example: branch on looked-up data

Combine conditions with [test data](https://docs.mozark.ai/no-code-studio/authoring-tests/test-data) to vary behaviour per device or per market.

| device\_serial   | region |
| ---------------- | ------ |
| 0002721R60000D2A | US     |
| R5CT10ABCDE      | IN     |

```
IF   ${region}  equals  "IN"
       Press Element   "Pay with UPI"
       Enter Text      ${upi_id}
ELSE
       Press Element   "Pay with card"
       Enter Text      ${card_number}
Assert Presence  Payment Successful|Payment Complete   (rule: any)
```

## Things to know

|                                      |                                                                                                |
| ------------------------------------ | ---------------------------------------------------------------------------------------------- |
| Numbers are whole numbers            | `>` and `<` compare integers. A decimal will not compare the way you expect. Use whole numbers |
| Empty branches are dropped           | A branch with no steps is not part of the test                                                 |
| Element clauses cost time when false | Every probe waits out its timeout before deciding the element is absent                        |
| Nesting is allowed                   | Put a condition inside a branch when the logic genuinely nests                                 |
| Modules work inside branches         | Insert a module block into a branch like any other step                                        |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.mozark.ai/no-code-studio/authoring-tests/conditions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.