SeleniumLibrary: Robot Framework Web Testing Setup

Why SeleniumLibrary Fits Robot Framework Browser Tests

SeleniumLibrary addresses a specific gap between Selenium and Robot Framework: Selenium exposes browser operations through Python, while Robot Framework organizes tests as declarative keywords and test cases. The library makes Selenium available to Robot Framework and adds named operations for actions such as opening a browser, entering text, clicking a button, and checking a page title.

Its intended users are teams writing web tests in Robot Framework, especially Python users who need Selenium 4 behavior without implementing the Robot Framework integration themselves. The package supports Python 3.10 through 3.13 according to the README, and it also works with PyPy. The package metadata requires Python 3.10 or newer. The setup metadata includes classifiers for Python 3.10 through 3.14, but the README explicitly documents support only through Python 3.13, so 3.14 should be checked with the project before being treated as documented compatibility.

The project is not a general test runner or browser-independent test framework. Robot Framework remains the test language and execution system, while Selenium supplies browser automation. SeleniumLibrary also does not replace Selenium itself. Its dependency list includes `selenium >= 4.25.0`, which means installation can introduce or update the underlying Selenium package as well as the Robot Framework integration.

Selenium 4 Execution Path and Robot Keyword Calls

A Robot Framework suite imports SeleniumLibrary through its settings, then calls its keywords as test steps. The keyword implementation delegates browser work to Selenium, which controls a browser and its driver. Selenium Manager handles browser and driver acquisition and management automatically, according to the README. That removes the need for a SeleniumLibrary-specific driver setup command in the documented installation flow.

The repository layout separates the package source under `src/`, unit tests under `utest/`, and acceptance tests under `atest/`. That separation is consistent with a Python package that has both internal package-level checks and broader Robot Framework behavior tests. The project also includes `gen_stub.py`, documentation directories, and development task configuration, indicating that the keyword surface is generated or maintained as part of the project tooling. The README does not describe those scripts as end-user commands.

The library supports a public plugin API. According to the README, that API can add keywords, modify existing keywords, change internal functionality, and support libraries built above SeleniumLibrary. This is an architectural choice worth noting. A new team-specific abstraction can sit above the library rather than requiring every project to fork the package, although the documentation excerpt does not specify plugin discovery, compatibility guarantees, or versioning policy.

Installing SeleniumLibrary and Its Selenium Dependencies

The README recommends installing or upgrading the library through `pip`. This is the normal starting point for a Python-based Robot Framework environment.

pip install --upgrade robotframework-seleniumlibrary

The command installs the latest Selenium and Robot Framework versions, as stated in the README. The `--upgrade` option can be omitted for an initial installation when an upgrade is not needed.

The project also documents direct installation from the repository. This path clones the project and can take longer because `pip` performs the source installation.

pip install git+https://github.com/robotframework/SeleniumLibrary.git

The dependency file lists the main lower bounds used by the project:

selenium >= 4.25.0
robotframework >= 6.1.1
robotframework-pythonlibcore >= 4.4.1
click >= 8.0

These are package requirements, not browser configuration values. The README does not provide a command for selecting a specific Selenium version, installing a browser, or pinning a driver. Browser and driver management is delegated to Selenium Manager. An engineer creating a controlled CI environment should therefore verify the installed Python, browser, Selenium, and Robot Framework versions separately.

A First Robot Framework Login Suite

The README recommends writing easy-to-understand tests and building higher-level Robot Framework keywords on top of SeleniumLibrary's lower-level keywords. The following settings and variables establish a local login page and Chrome as the browser.

*** Settings ***
Documentation     Simple example using SeleniumLibrary.
Library           SeleniumLibrary

*** Variables ***
${LOGIN URL}      http://localhost:7272
${BROWSER}        Chrome

The example uses custom keywords so the test case expresses intent rather than exposing every Selenium operation.

*** Test Cases ***
Valid Login
    Open Browser To Login Page
    Input Username    demo
    Input Password    mode
    Submit Credentials
    Welcome Page Should Be Open
    [Teardown]    Close Browser

The supporting keywords map those steps to SeleniumLibrary operations. `Open Browser` receives the URL and browser variable, `Title Should Be` checks the login page, and `Input Text` uses element identifiers such as `username_field`, `password_field`, and `login_button`.

*** Keywords ***
Open Browser To Login Page
    Open Browser    ${LOGIN URL}    ${BROWSER}
    Title Should Be    Login Page

The README's complete example is longer than this abbreviated illustration. For a real first run, use the complete example or the linked `WebDemo` project, because the page must expose the named fields and button. The README documents no server startup command or login application path for `http://localhost:7272`, so that part of the example is external to SeleniumLibrary.

Keyword-Level Limitations for Real Browser Suites

SeleniumLibrary's keywords are described as low level. Element locators and browser-specific arguments often need to be passed directly, which means the quality of a test depends on the locators and timing choices made by the test author. The higher-level Robot Framework layer is therefore important, but it also adds project-specific code that must be maintained.

The README does not document retry policies, implicit waits, screenshot behavior on failure, browser grid execution, parallel execution, proxy configuration, authentication, or rollback. It also does not document a supported migration path between SeleniumLibrary versions. Those omissions limit what can be concluded from the documentation. The library's presence in a suite should not be taken as proof that a particular CI browser policy or failure diagnostic workflow is configured.

There is another boundary: SeleniumLibrary is for web testing. It is the wrong choice when the target is an HTTP API without a browser interaction, a mobile-only test suite with no documented SeleniumLibrary support, or a desktop application. The README does not describe alternatives for those cases, so adopting this package requires matching the test target to Selenium's browser automation scope.

RobotFramework Libraries Versus Direct Selenium API Use

The practical alternative is a Robot Framework library built directly against Selenium, or using Robot Framework with a different browser abstraction. The difference is integration depth. SeleniumLibrary supplies an established keyword vocabulary, Selenium dependency handling, and extension points around Selenium. A direct Selenium implementation gives the team full control over Python calls and wrapper design, but the team must build and maintain its own Robot Framework keywords, locator conventions, browser lifecycle behavior, and failure handling.

For teams that want low-level control but already have a stable suite model, a thin custom library may be easier to constrain than a broad SeleniumLibrary dependency. For teams that want standard Robot Framework web tests quickly, SeleniumLibrary reduces the amount of integration code they need to write. The choice is not about Selenium itself, since SeleniumLibrary uses Selenium internally. It is about how much browser abstraction should live inside the test framework boundary.

The project is published under Apache License 2.0. That license permits use and modification under its terms, but this review does not interpret the license or provide legal advice. The repository includes `LICENSE.txt`, `COPYRIGHT.txt`, `BUILD.rst`, `CHANGES.rst`, and `VERSIONS.rst`, which are the relevant files for reviewing project-specific notices, build instructions, and version history.

SeleniumLibrary Maintenance and Upgrade Surface

The repository is not archived. Its last push was on 2026-08-13, and recent release records include v6.9.0 on 2026-05-17, v6.8.0 on 2025-10-04, and v6.7.1 on 2025-02-27. The presence of these releases and the recent push is evidence of ongoing repository activity, but it is not a compatibility guarantee for every browser or environment.

Upgrade cost comes from the dependency chain. The documented requirements include Selenium 4.25.0 or later, Robot Framework 6.1.1 or later, `robotframework-pythonlibcore` 4.4.1 or later, and Click 8.0 or later. A team upgrading SeleniumLibrary should review its release notes and existing test locators because changing Selenium, Robot Framework, or the wrapper's keyword implementation can affect browser interaction behavior. The README points to `VERSIONS.rst` for project history.

The practical adoption check is therefore specific: confirm the target Python version, browser, driver behavior, and existing Robot Framework syntax before changing the dependency. If those checks pass, SeleniumLibrary offers a practical bridge between Selenium 4 and Robot Framework without requiring a custom wrapper library.

Editorial conclusion

Adopt SeleniumLibrary when Robot Framework is already part of your test stack and browser UI coverage matters more than lower-level test code. Do not choose it for non-browser testing. Before adoption, verify that the target browsers, Python version, Robot Framework release, and Selenium dependency satisfy the project requirements.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. robotframework/SeleniumLibrary on GitHub