1. Overview
Context Switching is the process of redirecting automation focus from one browser context (such as a tab, window, iframe, or pop-up) to another. The primary purpose is to ensure the system interacts with the correct element during actions like clicking, inputting, or verifying, especially when execution needs to move between different browser environments.
How It Works
A Context Switch acts as a bridge, telling the runtime to move execution control from the current context to a new one. This is managed through two key attributes:
- Path: Represents the current tab or frame where execution is happening. It identifies the location of the element before the context switch.
- Target Path: Defines the destination tab or frame where execution should move next. It represents the element’s path after the switch is triggered.
Correctly setting these values is crucial for the runtime to interact with the intended browser context.
1.1 What Is Context Switching?
Definition: The process of redirecting automation focus from one browser context (tab, window, iframe, or pop-up) to another.
Purpose: Ensures the system interacts with the correct element during actions like click, input, or verify.
Analogy: Like moving from one layer of a page (tab) into another layer inside it (iframe).
Key Point: Context switching is required for automation to understand exactly where an element exists in complex web applications.
1.2 Common Use Cases
| Scenario | Description |
|---|---|
| Window/Tab Switching | Moving between the main browser window and new tabs (e.g., DB Explorer, API Explorer, external links). |
| Iframe Switching | Entering, exiting, or navigating between nested iframes to reach elements inside them. |
| Pop-up Handling | Focusing on alerts, confirmation dialogs, or temporary pop-up windows. |
2. How Context Switching Works (Technical Basics)
The system uses specific attributes—mainly managed by Architect and Front-end—to know where an element exists.
Key Terms
| Term | Purpose | Description |
|---|---|---|
| Path | Identifies element location | Indicates the frame, iframe, or pop-up where the element exists (e.g., iframe_2). Runtime uses this to switch context. |
| Target Path | Defines the destination of the context switch | Represents the element’s path after the context switch action is triggered. |
| Iframe Path Format | Handles nested iframes | Nested frames are combined with underscores, e.g., iframe_2_iframe_0. |
| Suffix | Differentiates similar contexts | A hidden, internal identifier used when multiple tabs or frames appear identical. |
2.1 How the System Determines Context
Recording: Architect captures element data, including iframe or window info.
Front-end Processing: Necessary context switch steps and paths are automatically inserted into the test.
Runtime Execution: Runtime switches to the correct frame based on the Path before performing actions like click or verify.
3. Advanced Use Cases & Best Practices
3.1 Page Object Parameterization
To use a Page Object across different contexts (e.g., same login form in a window and a pop-up):
Mark the element’s path as a variable (e.g.,
{{popup_path}}).This allows the Page Object to dynamically adjust to whichever context it’s used in.
Benefit: One Page Object can work in multiple flows, even if the element appears in different frames or pop-ups.
3.2 Using Context Switching Inside Loops (Use With Caution)
Context switching inside loops can be complex—especially with rapidly opening/closing tabs or iframes.
There are known challenges in this area, and test builders should be aware that additional tuning or troubleshooting may be required.