-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[DOCS-13406] Add guide for conditional logic in Synthetic tests #34792
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
git-thuerk-done
wants to merge
6
commits into
master
Choose a base branch
from
alicia/docs-13406-conditional-logic-synthetic-tests
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+99
−0
Open
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
1f78168
[DOCS-13406] Add guide for conditional logic in Synthetic tests
git-thuerk-done 1996c93
[DOCS-13406] Add images and product identifiers to conditional logic …
git-thuerk-done 9d0320e
Update content/en/synthetics/guide/conditional-logic-subtests.md
git-thuerk-done 168c107
Merge branch 'master' into alicia/docs-13406-conditional-logic-synthe…
git-thuerk-done aeb4fb8
Apply suggestions from Dom's review
git-thuerk-done 98b9465
additional updates from Dom's review
git-thuerk-done File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,98 @@ | ||
| --- | ||
| title: Implement Conditional Logic in Synthetic Tests | ||
| further_reading: | ||
| - link: '/synthetics/browser_tests/advanced_options' | ||
| tag: 'Documentation' | ||
| text: 'Configure Advanced Options for Browser Test Steps' | ||
| - link: '/synthetics/browser_tests/test_steps#subtests' | ||
| tag: 'Documentation' | ||
| text: 'Browser Test Steps' | ||
| - link: '/synthetics/multistep' | ||
| tag: 'Documentation' | ||
| text: 'Multistep API Tests' | ||
| products: | ||
| - name: Browser Tests | ||
| url: /synthetics/browser_tests/ | ||
| icon: browser | ||
| - name: Multistep API Tests | ||
| url: /synthetics/multistep/ | ||
| icon: synthetics | ||
| - name: Mobile App Testing | ||
| url: /synthetics/mobile_app_testing/ | ||
| icon: mobile | ||
| --- | ||
|
|
||
| {{< product-availability >}} | ||
|
|
||
| ## Overview | ||
|
|
||
| Conditional branching allows your Synthetic Monitoring tests to adapt to different application states and execute different paths based on runtime conditions. Instead of following a single linear sequence, a test can decide which steps to run, skip, or continue after failures. | ||
|
|
||
| This guide covers three use cases for conditional branching. Each use case applies one or more of these step execution options: | ||
| - If this step fails, continue to next step | ||
| - If this step succeeds, stop this test and mark it as passed | ||
| - Always run this step | ||
|
|
||
| ## Run different test paths based on application state | ||
|
|
||
| Use this pattern when your application can show different UI states, such as in A/B tests, and you want a single test that executes different steps depending on which state it encounters. | ||
|
|
||
| **Example logic:** | ||
| - If journey A header is found, run journey A steps | ||
| - Else, if journey B header is found, run journey B steps | ||
|
|
||
| To set up this pattern: | ||
|
|
||
| 1. Create a subtest that represents journey A: | ||
| - Add a step that checks for the journey A element (for example, a step that asserts or clicks on a journey A header). | ||
| - Add the remaining journey A steps inside that subtest. | ||
| 2. In the subtest's advanced options, enable the following: | ||
| - **If this step fails, continue to next step**: Prevents a failure from stopping the entire test. | ||
| - **If this step succeeds, stop this test and mark it as passed**: Ends the test and does not run the other journey when journey A is found. | ||
| 4. Add a second subtest for journey B: a step that checks for the journey B element, followed by the journey B steps. | ||
| 5. Enable **If this step fails, continue to next step** on the journey B subtest. | ||
| 6. Order the subtests so the test runs journey A first, then journey B. Whichever condition matches runs to completion; the other subtest fails silently and the test continues. | ||
|
|
||
| {{< img src="synthetics/guide/conditional_logic/subtests.png" alt="Subtest configuration showing if/else step execution options" style="width:60%;" >}} | ||
|
|
||
| For more information on subtest configuration options, see [Subtests][1]. | ||
|
|
||
| ## Interact with the first available element | ||
|
|
||
| Use this pattern when you need to interact with the first available option, such as selecting an in-stock product size or the first available item in a list. | ||
|
|
||
| **Example logic:** | ||
| - If product A is available, proceed to purchase | ||
| - Else, if product B is available, proceed with product B | ||
| - Else, skip to the next available product | ||
|
|
||
| To set up this pattern: | ||
|
|
||
| 1. Add a step that interacts with the target element (for example, clicking an **add to cart** button or selecting a size from a **select a size** dropdown). | ||
| 2. In the step's advanced options, set a **User Specified Locator** using XPath or CSS that targets only available elements (for example, `.size.available` or a class that indicates in-stock status). | ||
| 3. Enable **If this step fails, continue to next step** so the test continues if no matching element is found. | ||
| 4. Add a follow-up step or subtest that tries the next option (for example, a different size or product). | ||
| 5. If the UI has filters or search, add steps that narrow the page to available items first so the locator targets only the correct elements. | ||
|
|
||
| {{< img src="synthetics/guide/conditional_logic/if_this_step_fails.png" alt="Step advanced options showing User Specified Locator and allow failure settings" style="width:60%;" >}} | ||
|
|
||
| ## Always run specific steps | ||
|
|
||
| Use this pattern when certain steps must always run regardless of earlier results, such as logging out, releasing resources, or capturing error state. | ||
|
|
||
| To set up this pattern: | ||
|
|
||
| 1. Add a subtest at the end of your test that contains only the cleanup or teardown steps. | ||
| 2. In the subtest's advanced options, enable **Always run this step**. | ||
| 3. Save the test. The cleanup subtest runs even when earlier steps have failed. | ||
|
|
||
| {{< img src="synthetics/guide/conditional_logic/always_run_step.png" alt="Subtest advanced options with Always run this step enabled" style="width:60%;" >}} | ||
|
|
||
| For more information, see [Set execution behavior][2]. | ||
|
|
||
| ## Further reading | ||
|
|
||
| {{< partial name="whats-next/whats-next.html" >}} | ||
|
|
||
| [1]: /synthetics/browser_tests/advanced_options#subtests | ||
| [2]: /synthetics/browser_tests/advanced_options#set-execution-behavior | ||
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added
BIN
+87 KB
static/images/synthetics/guide/conditional_logic/if_this_step_fails.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the "always run this step" apply even if we have "If this step succeeds, stop this test and mark it as passed" earlier up in the chain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes for this we want to capture the error and continue directly to step X from the step where it failed (i.e. in this pattern we don't want the "If this step succeeds, stop this test and mark it as passed" condition). hope that makes sense!