Selenium Ecosystem, Installation, and First WebDriver Session: Configuration, Design Patterns, and Trade-Offs

1. Automatic Manager versus explicit driver service

Selenium Manager default: minimal project configuration, less manual browser/driver drift, built-in cache and resolution, and consistent behavior across the core bindings. This is the best Chapter 02 default.

Explicit driver service: useful when an organization distributes a reviewed driver binary, a hermetic build image already contains a driver, or diagnostic policy requires an exact executable and service log. The tradeoff is ownership: once you provide the executable path, your environment is responsible for keeping it compatible.

from selenium import webdriver

# Default management path: binding can invoke Selenium Manager.
driver = webdriver.Chrome()
driver.quit()

# Explicit path: your environment owns this executable/version.
service = webdriver.ChromeService(executable_path="/approved/tools/chromedriver")
driver = webdriver.Chrome(service=service)
driver.quit()

2. System browser versus Selenium-Manager-managed browser

Using the system browser is simple and mirrors what developers already run, but evergreen browser updates can change the environment between test runs. Selenium Manager can also manage Chrome, Firefox, and Edge browser releases and supports browser-version requests such as fixed major versions or channel labels where applicable. That can improve controlled compatibility testing, but it may download large browser assets and introduces cache/network governance.

from selenium import webdriver

options = webdriver.ChromeOptions()
options.browser_version = "stable"   # current stable channel request

driver = webdriver.Chrome(options=options)
print(driver.capabilities.get("browserVersion"))
driver.quit()

The capability request does not excuse you from recording the returned version. In CI, decide whether browser rollout should follow the host image, a managed browser label, or a pinned image/version policy. Make that an explicit platform decision rather than letting developer laptops define the release matrix.

3. Headed versus headless

Headed execution is valuable while learning, debugging rendering/focus behavior, and watching the first workflow. Headless execution reduces display-server requirements and is common in CI, but it is still a real browser mode with its own environment, viewport, GPU, font, extension, and policy conditions. A test that passes headed and fails headless is not automatically “a Selenium bug”; compare the actual browser arguments, viewport, rendering resources, and application evidence.

Keep the mandatory Chapter 02 path headed unless your environment cannot display a browser. Headless flags are browser-vendor behavior and can evolve, so verify the current browser documentation before standardizing a flag across a fleet.

4. Pin binding dependencies; manage browser upgrades intentionally

selenium==4.47.0 makes the Python API surface reproducible for this chapter. Floating pip install -U selenium in every CI run can change client behavior without a code review. Conversely, freezing a browser forever can hide compatibility regressions and create security risk. Mature teams separate those concerns:

• pin project dependencies in reviewed files;
• upgrade Selenium deliberately with changelog review;
• define browser channels/versions in the test-platform contract;
• record returned browser/driver capabilities on every run;
• exercise browser upgrades in a controlled compatibility job before changing release gates.

5. One primary teaching binding versus cross-binding comparison

Python is the primary binding for this course chapter so the learner can focus on browser semantics rather than language syntax. The core lifecycle is shared across supported bindings: create options/service as needed, create a driver/session, send commands, inspect results, and quit. Method names and framework integration differ, and some new features reach bindings at different times. Cross-binding snippets should therefore clarify a real portability issue—not multiply every example five times.

6. Worked decision table

The following table organizes the key choices and evidence for Worked decision table. Use it together with the surrounding prose so the rows serve as a comparison aid rather than standalone rules.

7. Design exercise

For each of these environments—developer laptop, locked-down corporate workstation, Linux CI runner, and a future Grid node—write a six-line configuration decision record:

1. binding/version policy;
2. browser source/version policy;
3. driver management owner;
4. network/proxy/cache assumptions;
5. headed/headless mode and why;
6. evidence required before a browser failure can be triaged.

Do not choose “latest everywhere” as a substitute for policy. “Latest” changes over time; a production record needs a review/update mechanism.

Knowledge check

Official references and version notes

• Selenium 4.47 release notes — release baseline for this chapter.
• Selenium downloads — current stable language bindings and Selenium Server/Grid status.
• Install a Selenium library — project dependency installation and the current selenium==4.47.0 example.
• WebDriver getting started and first script — browser/driver roles and first-session lifecycle.
• Selenium Manager — automated driver/browser discovery, download, cache, configuration, proxy, offline, PATH-skip, debug, and cache settings.
• Driver Service class — explicit local driver-service configuration and logging.
• Browser options — W3C capabilities and browser-specific options.
• Unable to locate driver — supported driver-location troubleshooting.
• Selenium Python 4.47.0 — Python 3.10+ requirement and package metadata.