How to Automate Opera Browser Testing with Selenium and Python

To automate desktop Opera with Selenium 4, use Opera’s OperaChromiumDriver, start its service, create Selenium ChromeOptions, point those options at the Opera executable if it is not detected automatically, and connect with webdriver.Remote(). The Opera project documents this browser-specific route. Do not assume that webdriver.Opera() or Selenium Manager will configure current Opera for you.

The example below shows the documented construction pattern and a small test. It is not a claim that a particular current combination of Opera, OperaDriver, Selenium, Python, and operating system was tested. The Opera desktop guide’s latest commit is dated March 9, 2023, and does not provide a current compatibility matrix. Check the versions available for your environment before adopting it.

1. Check compatibility before you install

OperaChromiumDriver is Opera’s WebDriver implementation for Chromium-based Opera. Its project documentation includes Python and Selenium examples. The desktop guide says to use RemoteWebDriver to drive Chromium-based Opera, and describes supplying the browser executable, allowing the driver to detect it, or connecting to an already-running browser.

Selenium’s current Python documentation supports Python 3.10 and newer and documents Selenium Manager for driver and browser management across most supported combinations. Opera does not appear among the browser-specific sections on Selenium’s Supported Browsers page. Follow Opera’s driver instructions for Opera rather than assuming Selenium Manager supplies or configures OperaDriver.

Record your operating system and architecture, Python version, Selenium version, Opera version, and OperaDriver version.
Check the OperaChromiumDriver project and its desktop guide for current instructions and release information.
Confirm that the driver can work with the Chromium build in your installed Opera. The cited documentation does not establish a current, universal version matrix.
Run a small local smoke test before depending on the setup in CI. Keep the exact versions and environment details with the test run so failures can be reproduced.

The examples use Selenium 4’s API shape. Install Selenium with:

python -m pip install -U selenium

Download or install OperaDriver according to the Opera project’s current instructions, then note the absolute path to the executable. Also note Opera’s executable path if automatic detection is unsuitable. Paths vary by operating system and installation method; use the actual paths on your machine.

2. Start OperaDriver and connect with Selenium 4

This script starts a local OperaDriver service, explicitly selects the Opera binary, opens a page, prints its title, and closes both the WebDriver session and service, including when a navigation or assertion fails.

from pathlib import Path

from selenium import webdriver
from selenium.webdriver.chrome.service import Service

OPERA_DRIVER = Path("/path/to/operadriver")
OPERA_BINARY = Path("/path/to/opera")
TARGET_URL = "https://example.com"

if not OPERA_DRIVER.is_file():
    raise FileNotFoundError(f"OperaDriver not found: {OPERA_DRIVER}")
if not OPERA_BINARY.is_file():
    raise FileNotFoundError(f"Opera executable not found: {OPERA_BINARY}")

service = Service(executable_path=str(OPERA_DRIVER))
options = webdriver.ChromeOptions()
options.binary_location = str(OPERA_BINARY)
options.add_experimental_option("w3c", True)

driver = None
try:
    service.start()
    driver = webdriver.Remote(
        command_executor=service.service_url,
        options=options,
    )
    driver.get(TARGET_URL)
    print(driver.title)
finally:
    if driver is not None:
        driver.quit()
    service.stop()

The use of ChromeOptions is intentional: OperaChromiumDriver is based on ChromeDriver and the Opera desktop guide’s Selenium 4 example uses Selenium’s Chrome options with RemoteWebDriver. The w3c experimental option appears in that upstream example; retain it when following that documented pattern, and check the current Opera guide if a newer release changes its requirements.

Replace both placeholder paths with real paths. On systems where the driver executable is already on the path, you can still supply an explicit path for predictable setup. If the driver is expected to detect Opera, omit options.binary_location only after confirming that detection works for your installation.

3. Write a test with stable selectors and explicit waits

Once the session starts, use normal Selenium WebDriver operations. Prefer selectors tied to stable application attributes, and wait for the page state your test needs instead of relying on arbitrary sleep intervals.

This example assumes a page under your control with an element whose ID is status. Adapt the URL and selector to your application.

from pathlib import Path

from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.support.ui import WebDriverWait

OPERA_DRIVER = Path("/path/to/operadriver")
OPERA_BINARY = Path("/path/to/opera")
TARGET_URL = "https://example.com/your-test-page"

service = Service(executable_path=str(OPERA_DRIVER))
options = webdriver.ChromeOptions()
options.binary_location = str(OPERA_BINARY)
options.add_experimental_option("w3c", True)

driver = None
try:
    service.start()
    driver = webdriver.Remote(service.service_url, options=options)
    driver.set_page_load_timeout(45)
    driver.get(TARGET_URL)

    status = WebDriverWait(driver, 15).until(
        EC.visibility_of_element_located((By.ID, "status"))
    )
    assert status.text == "Ready", f"Unexpected status: {status.text!r}"
finally:
    if driver is not None:
        driver.quit()
    service.stop()

Use WebDriverWait for conditions such as visibility, clickability, or a particular URL. Choose a timeout that reflects the page and test environment. A timeout should fail with useful context; it should not be hidden by repeatedly extending waits until a flaky test happens to pass.

4. Choose how Opera starts

The Opera desktop documentation describes three connection approaches. Choose based on how much control you need over browser startup.

Approach	What to configure	Useful when	Tradeoff
Driver launches a specified Opera executable	Set `options.binary_location` to the Opera binary and connect through the started service.	You need an explicit, reproducible browser path, such as on a CI worker.	You must maintain the correct path and a compatible OperaDriver/browser combination.
Driver detects Opera	Leave the binary path unset and let OperaDriver locate Opera.	Opera is installed in a location the driver recognizes.	Detection depends on the installation location and environment; it may fail on custom installs.
Attach to an existing Opera instance	Start Opera with a remote debugging port, then configure the corresponding debugger address capability as described by the Opera guide.	A workflow needs to connect to a browser started separately.	You must manage browser startup and the debugging endpoint yourself. This differs from letting WebDriver launch Opera.

For the attach approach, the Opera guide’s pattern requires starting Opera with --remote-debugging-port and providing the matching debugger address capability. Follow the current Opera desktop instructions for the exact capability syntax for the release you use. Avoid copying older Selenium 2 or 3 desired-capability snippets into a Selenium 4 options-based script without adapting them to the current API.

5. Run the test as a repeatable script

Install a specific Python environment and Selenium version for the project; record the version used.
Install Opera and OperaDriver using sources and instructions you can maintain.
Set the executable paths explicitly when browser detection is unreliable.
Start a new WebDriver session for the test run, navigate to the target page, and wait for a meaningful application condition.
On failure, capture useful diagnostics such as the current URL, page title, exception, and driver logs where available.
Always call driver.quit() and stop the locally started service in cleanup code.

For a test suite, put session setup and teardown in your test framework’s fixture or equivalent. Keep browser paths and timeouts in configuration rather than scattering them through tests. Avoid sharing one live driver session between tests that can change browser state, cookies, or the current page.

6. Troubleshoot startup and test failures

Symptom	Likely cause	What to check or change
OperaDriver executable not found	The path is wrong, the executable is not installed, or the process cannot execute it.	Check the absolute path, file permissions, and operating-system-specific install location. Use `Path.is_file()` as in the example and follow OperaDriver’s installation instructions.
Driver starts, but Opera does not launch or the session cannot be created	Opera was not detected, the binary path is wrong, or the driver and browser builds are incompatible.	Set `options.binary_location` explicitly, verify the path points to the browser executable, and check the OperaDriver release against the installed Opera/Chromium build. The reviewed sources do not supply a reliable current compatibility matrix.
Session creation fails with an unknown or unsupported capability	Capabilities may come from an older Selenium example or may not match the OperaDriver version.	Use Selenium 4’s `ChromeOptions` and `webdriver.Remote()` pattern from Opera’s desktop guide. Check the current guide for capability names before adding custom capabilities.
Python reports that an option or method is missing	The snippet may use an API from a different Selenium generation, or the active Python environment may not have the expected Selenium package.	Check `python -m pip show selenium` using the same interpreter that runs the script. Prefer the Selenium 4 options-based example and consult the current Selenium Python API documentation.
Browser opens, but navigation hangs or times out	The page may be slow, unreachable from the test environment, or waiting on resources indefinitely.	Confirm the URL is reachable from the machine running the test. Set an appropriate page-load timeout and use explicit waits for the page state your test needs. Report the current URL and exception on failure.
Element lookup fails immediately	The element may not exist yet, the selector may be wrong, or the page may have changed.	Verify the selector against the current page and wait for the element’s expected condition. Prefer stable IDs or test attributes over fragile positional selectors.
Element is found but interaction fails	The element may not be visible or clickable yet, or another page state may cover it.	Wait for visibility or clickability and assert the surrounding state. Do not treat a fixed sleep as proof that an element is ready.
Opera stays open after the test	The session or service was not cleaned up after an exception.	Put both `driver.quit()` and `service.stop()` in a `finally` block or test-framework teardown. Only call `quit()` after a driver session was created.
Attaching to Opera fails	Opera was not launched with remote debugging enabled, or the configured debugger address does not match the listening port.	Start Opera with `--remote-debugging-port` and use the matching debugger address capability from the current Opera desktop guide. Confirm the port is available and the browser process is still running.
Assumed Selenium Manager setup does not work for Opera	Selenium documents Manager for most supported browser combinations, but its supported-browser page does not list Opera in its browser-specific sections.	Use Opera’s OperaChromiumDriver instructions and configure that driver explicitly unless current authoritative documentation confirms a supported automatic setup.

When reporting an issue, include the operating system, Python and Selenium versions, Opera and OperaDriver versions, executable paths with sensitive directory details removed if needed, and the full exception. This information helps distinguish a path problem from a browser-driver compatibility problem.

7. Performance, reliability, and cost

Performance

Browser startup and page loading are part of the work of a real browser test. Keep each test focused, avoid navigating repeatedly when one session can safely serve a small related scenario, and wait for the state that matters instead of an unnecessarily long fixed delay. A longer timeout can prevent false failures on a slow environment, but it also increases how long a genuine failure takes to report.

Reliability

Opera-specific setup adds a browser binary and driver release to maintain. Pin and record the versions your team selects, verify the combination in the actual target environment, and revisit it when either Opera or OperaDriver changes. The cited Opera guide dates to 2023, so its example demonstrates the setup pattern rather than proving compatibility with every current release. Use explicit waits, stable selectors, diagnostic output, and unconditional cleanup to make failures easier to understand.

Cost

Selenium and OperaChromiumDriver are software components; this guide does not assert a price for either. The practical costs are the time and infrastructure needed to install and maintain browser and driver versions and run browser sessions. If you only need a rendered screenshot rather than interactive browser testing, a screenshot API may avoid managing a local browser session.

Or skip the browser setup

If your goal is to capture a webpage image rather than interact with it in an Opera test, ScreenshotNeo provides a website screenshot API and MCP server. The API takes one GET request with a URL and returns an image or PDF. See the ScreenshotNeo API documentation for options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie and consent banners are accepted like a visitor; more than 60 known consent platforms, newsletter popups, and chat widgets are removed before the shot. Each step can be turned off.
Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed. Response headers report the page verdict and billing status.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents, including Claude, Cursor, and other MCP clients.
The free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 screenshots. Every feature is available on every plan.

Frequently asked questions

Can I use Selenium’s `webdriver.Opera()`?

Do not rely on that as the current Selenium 4 setup. Opera’s desktop documentation describes OperaDriver with Selenium’s Chrome options and webdriver.Remote().

Does Selenium Manager install OperaDriver?

The Selenium documentation reviewed describes Manager for most supported browser combinations, but does not promise Opera support. Use Opera’s driver instructions unless current authoritative documentation says otherwise.

Can I automate Opera on Android with this desktop script?

No. This guide covers desktop Opera. The Opera repository includes Android and Appium material, but the available setup documentation does not verify current Android compatibility. Check those instructions afresh before using that route.

Do I need to set the Opera binary path?

Set options.binary_location when the driver cannot find Opera or when you need to select a specific installation. Opera’s documentation also describes driver detection and attaching to a running instance.