> For the complete documentation index, see [llms.txt](https://docs.bugbug.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bugbug.io/editing-tests/conditional-logic-if-else.md).
# Conditional Logic (if/else)
How the BugBug If condition step works: conditions, how and when the condition is checked, skipped steps, limits, patterns instead of else, and the YAML and API format.
An **If condition** step checks a condition and runs the steps inside its block only when the condition is met. If it isn't met, the steps are skipped and the test continues. A condition that isn't met never fails the test.
Use it for things your app doesn't always show, for example a cookie banner, a promo popup, or a "session already exists, log in anyway?" dialog.
## Conditions
A condition works exactly like an [assertion](/editing-tests/assertions.md): the same checks, operators, expected values and case sensitivity. For example: **Element is visible**, **Element has text**, **URL address**, **Variable value** or **Custom JavaScript**. See the [list of assertions](/editing-tests/assertions.md#all-assertions-at-a-glance).
## Add an If condition
1. Add a new step and choose **If condition**.
2. Choose the condition and set it up like an assertion.
3. Put the steps that should run only when the condition is met inside the block. Drag the end of the block to include more steps.
You can't add an If condition while recording. Pause the recording and add it manually; [Edit & Rewind](/workflow-tips/edit-and-rewind.md) helps here.
Example: if the text "Force" is visible, click the button with that text.
## How the condition is checked
* **The condition is checked once.** Unlike an assertion, it isn't retried. If it's met, the block runs; if not, the steps in the block are marked as *skipped*.
* **DOM element exists, DOM element does not exist and Element is visible are checked immediately.** BugBug doesn't wait for the element to appear. If the element shows up with a delay, for example an animated modal, the condition can be false. Put a step before the condition that waits for the page, such as an assertion on something that always appears.
* **Other element conditions wait for the element.** For example, **Element has text** waits until the element exists and meets its [waiting conditions](/preventing-failed-tests/waiting-conditions.md). If the element doesn't appear before the step's timeout, the test fails with the `ELEMENT_DOES_NOT_EXIST` [error code](/debugging-tests/error-codes.md). For elements that may be missing, use **DOM element exists** or **Element is visible**.
## Limits
* **No else and else if.** Use the patterns below.
* **No nested conditions.** An If condition can't be inside another If condition.
* **No components inside the block.** You can't insert a [component](/editing-tests/components.md) into an If condition block. Instead, put the If condition inside the component, and check a [local variable](/editing-tests/local-variables.md) that the test sets before the component.
* **No loops.** BugBug can't repeat steps until a condition is met.
## Patterns instead of else
**Two opposite conditions.** Add one If condition with **DOM element exists** and a second one with **DOM element does not exist** for the same selector. Only one of the blocks runs. Both are checked immediately, so neither fails when the element is missing.
**A variable.** Save a value with a [Set variable](/editing-tests/actions.md#set-variable) step, then add one If condition per value with **Variable value**.
**Close it if it's there.** For popups that appear only sometimes, add an If condition with **Element is visible** on the popup and put the click that closes it inside the block.
[Contact us](https://bugbug.io/contact/) if you have a scenario you can't cover.
## YAML and API
In [YAML](/export-import-and-backup/yaml-schema.md) the step is `action: ifCondition`. The condition uses the same fields as an [assertion](/editing-tests/assertions.md#fields), and the steps inside the block are listed in `conditional_steps`:
```yaml
- action: ifCondition
action_details:
selector: "xpath=//*[contains(@class, 'cookie-banner')]"
assertion_property: visible
assertion_type: equal
assertion_expected_value: true
conditional_steps:
- action: click
action_details:
selector: "xpath=//*[contains(@class, 'cookie-banner')]//button"
```
In the API and MCP, create a step with `type: "ifCondition"`, then create the steps for its block with `blockId` set to the ID of the If condition step. Steps without `blockId` are outside the block.
---
# 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.bugbug.io/editing-tests/conditional-logic-if-else.md?ask=&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.
