You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add DriverWrapper.connect_cdp for CDP browser connections
Problem:
MOPS requires users to manually create driver objects when connecting to
remote browsers via Chrome DevTools Protocol (CDP). This involves
boilerplate code for lifecycle management and cleanup.
Use cases:
- Testing Electron apps on remote machines via CDP + SSH tunnel
- Connecting to cloud browser services (BrowserStack, Sauce Labs)
- Attaching to an already-running browser instance for debugging
- Testing CEF-based or WebView2 applications
Solution:
Add a factory classmethod DriverWrapper.connect_cdp(endpoint_url) that
handles the full lifecycle. Supports both Playwright and Selenium engines
via the engine parameter (default: "playwright").
Playwright engine:
Starts Playwright, connects via chromium.connect_over_cdp, wraps the
resulting page. Playwright instance is stopped on quit().
Selenium engine:
Creates Chrome WebDriver with debugger_address option pointing to the
CDP endpoint.
Architectural changes:
- DriverWrapper.is_cdp flag: identifies CDP-connected wrappers, used by
PlayDriver.quit() to skip tracing on pre-existing CDP contexts
- PlayDriver.quit(): tracing.stop() skipped for CDP (not just caught);
page.close() and context.close() wrapped in try/except
- CoreDriver.quit(): wrapped in try/except for externally-managed browsers
- PlayDriver.get_inner_window_size(): null-safe for CDP default viewport
API:
- DriverWrapper.connect_cdp(endpoint_url, engine, timeout, page_index,
viewport_size) — main entry point
- DriverWrapperABC.connect_cdp() — abstract interface
- DriverWrapper.is_cdp — bool flag (False by default, True after connect_cdp)
Version bump: 3.3.1 -> 3.4.0
Documentation:
- Getting Started: CDP section with both engine examples + limitations
- Index: CDP listed in key features
- DriverWrapper overview: CDP mentioned in description and status attrs
- CHANGELOG: v3.4.0 entry
Tests: 14 unit tests covering both engines, is_cdp flag, URL parsing,
parameters, cleanup, sessions, and compatibility
Made-with: Cursor
Copy file name to clipboardExpand all lines: docs/source/driver_wrapper/index.md
+5-1Lines changed: 5 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,6 +15,10 @@ The `DriverWrapper` module provides a unified interface to interact with differe
15
15
such as _Selenium_, _Appium_, and _Playwright_. It abstracts the complexities of these frameworks and offers a seamless
16
16
experience for managing driver sessions, performing operations, and handling cross-platform automation tasks.
17
17
18
+
It also supports connecting to remote browsers via **Chrome DevTools Protocol (CDP)** using the
19
+
`DriverWrapper.connect_cdp()` class method, enabling testing of Electron applications, cloud browser
20
+
services, and pre-existing browser instances.
21
+
18
22
<br>
19
23
20
24
### Core Benefits & Rules
@@ -26,7 +30,7 @@ experience for managing driver sessions, performing operations, and handling cro
26
30
- The `DriverWrapper` and its underlying `Driver` instance are easily accessible within your `Page`, `Group`, and `Element` objects, allowing for consistent and efficient interactions across your test suite.
27
31
28
32
3.**Dynamic Status Attributes:**
29
-
-`DriverWrapper` provides various status attributes (e.g., `is_mobile`, `is_selenium`, `is_playwright`) that help you tailor your test behavior based on the current driver environment, ensuring more precise control and adaptability in your tests.
33
+
-`DriverWrapper` provides various status attributes (e.g., `is_mobile`, `is_selenium`, `is_playwright`, `is_cdp`) that help you tailor your test behavior based on the current driver environment, ensuring more precise control and adaptability in your tests.
30
34
31
35
4.**Optimal Driver Setup:**
32
36
- The initialization of the source driver should be handled within your testing framework. This approach ensures that the browser or device starts with the most appropriate configuration, leading to more reliable and efficient test executions.
Copy file name to clipboardExpand all lines: docs/source/index.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,6 +17,7 @@ process, giving you the flexibility and power to automate complex testing scenar
17
17
-**Seamless Integration**: Mops integrates with Selenium, Appium, and Playwright, allowing you to use the best-suited engine for your specific testing needs.
18
18
-**Unified API**: A single, easy-to-use API that abstracts away the differences between Selenium, Appium, and Playwright, making your test scripts more readable and maintainable.
19
19
-**Engine Switching**: Switch between Selenium, Appium, and Playwright within the same test case, enabling cross-platform and cross-browser testing with minimal effort.
20
+
-**CDP Connection**: Connect to remote browsers via Chrome DevTools Protocol using `DriverWrapper.connect_cdp()` — ideal for Electron apps, cloud browser services, and pre-existing browser instances. Both Playwright and Selenium engines are supported.
20
21
-**Visual Regression Testing**: Perform visual regression tests using the integrated visual regression tool, available across all supported frameworks. This ensures your UI remains consistent across different browsers and devices.
21
22
-**Advanced Features**: Leverage the advanced features of each framework, such as Playwright's mocks and Appium's real mobile devices support, all while using the same testing framework.
22
23
-**Extensibility**: Extend the framework with custom functionality tailored to your project's specific requirements.
0 commit comments