SeleniumLibrary and Browser Automation Integration: Core Concepts and Mental Model

1. The problem: Robot makes browser tests readable, but the browser still owns real state

The preceding chapters built a reliable Robot execution model: explicit variables, lifecycle, control flow, failure semantics, result evidence, and command-line selection. Browser automation adds a second execution system underneath Robot. A keyword such as Sign In As may look like one business step, but underneath it a browser library locates elements, interacts with a browser engine, changes page/session state, waits for conditions, and returns observations to Robot.

The dedicated Selenium course already teaches browser-testing fundamentals. This chapter does not repeat WebDriver theory, selector fundamentals, or browser administration. Instead it answers the Robot-specific question: where should browser capability enter a Robot project, which layer owns lifecycle, and how do we preserve truthful evidence?

2. Read-only preflight before any browser mutation

python --version
python -m robot --version
python -m pip show robotframework-seleniumlibrary selenium robotframework-browser
# Browser only, if installed:
rfbrowser --version
# Confirm the local target is loopback before opening a browser.
python -c "import urllib.request; print(urllib.request.urlopen('http://127.0.0.1:8765/', timeout=2).status)"

Version inspection changes no browser or application state. The HTTP probe reads only the loopback fixture. Record the Python interpreter, Robot version, library versions, browser-engine prerequisites, target URL, current working directory, and existing result directory before execution. If the URL is not loopback/private and explicitly approved, stop.

3. Mental model: one Robot step crosses several ownership boundaries

flowchart TD
A[Robot test] --> B[Domain user keyword / resource]
B --> C{Browser library boundary}
C -->|SeleniumLibrary| D[Selenium WebDriver]
C -->|Browser| E[Playwright via Browser node side]
D --> F[Browser session]
E --> G[Browser + context + page]
F --> H[Local AUT]
G --> H
H --> I[DOM / URL / application state]
I --> C
C --> B
B --> J[Assertion + Robot status]
J --> K[output.xml / log / screenshot / trace]

The first arrow is intent: the test says what outcome matters. The resource turns that intent into browser operations. SeleniumLibrary delegates to Selenium/WebDriver; Browser delegates to Playwright through its own runtime. Both mutate a real browser. The browser mutates or observes the local application. Assertions return truth to Robot, which owns the test status and result files. A screenshot or trace is evidence of browser state, not the browser state itself.

4. Define every state store before using it

5. SeleniumLibrary stack versus Browser stack

SeleniumLibrary is a Robot test library over Selenium 4. Opening a browser creates a WebDriver session. Modern Selenium uses Selenium Manager to resolve/manage browser drivers on supported platforms, but the actual browser must still be available and network-restricted machines may need pre-provisioning.

Browser is a Robot library over Playwright. Its model is explicit: a browser can own one or more contexts, and a context owns pages. Browser 20.4.0 can be installed with BrowserBatteries so the learner does not have to manage Node manually; Playwright browser binaries are then installed with rfbrowser install, or a preinstalled Chrome/Edge channel can be used.

6. Domain keywords are the stability seam

Do not let business-facing tests become selector scripts. The test should say Sign In As and Welcome Should Be Visible. A resource owns concrete selectors and library calls. This isolates implementation churn: replacing a CSS locator or changing browser stacks should not force every business test to change.

*** Test Cases ***
User Can Sign In
    Sign In As    demo    mode
    Welcome Should Be Visible    demo

The test owns scenario intent; the resource owns browser mechanics; the external library owns engine calls; the browser owns cookies/DOM/page state. That dependency direction is the maintainability payoff of Robot Framework.

7. Waiting is a contract, not a delay

SeleniumLibrary waits are explicit polling assertions: for example, Wait Until Element Is Visible repeatedly checks a locator until it is visible or the bounded timeout fails. Browser benefits from Playwright actionability waiting for actions such as Click. Browser also retries getter assertions such as Get Text … == …; a getter used only to return a value does not gain that assertion retry. When readiness is not the direct action/assertion condition, use a condition-specific wait—not Sleep.

8. Library lifecycle is not browser lifecycle

Importing SeleniumLibrary or Browser makes keywords available. It does not mean a browser is already open. Conversely, closing a page is not necessarily closing a browser runtime. In this course, the safe default is per-test browser isolation unless an exercise explicitly proves a different ownership model. The setup opens exactly what the test owns; teardown closes exactly that owned browser state.

Never “clean up” by killing every Chrome, Firefox, Edge, WebDriver, or Node process on the machine. That can destroy unrelated developer sessions and CI workers. Use library-level handles and lifecycle keywords.

9. Browser evidence is useful—and sensitive

A screenshot can expose typed values, names, URLs, and account state. A Playwright trace can be even richer: DOM snapshots, network-related information, console messages, and action history may reveal more than a screenshot. This chapter uses synthetic credentials only. In production, artifact retention and access controls are part of the test design, not a postscript.

10. DevOps connection

Browser tests are usually slower and more stateful than API/unit checks. Robot gives them a readable orchestration layer, but CI trust still depends on deterministic selection, isolated browser state, bounded waits, precise failures, and retained artifacts. A browser test that “passes after a sleep” is weaker evidence than one whose readiness condition and lifecycle are explicit.

Knowledge check

11. Summary and bridge

The browser integration model is now explicit: Robot intent → domain resource → external browser library → browser engine/state → assertions → evidence. Lesson 2 turns that model into a disposable local workflow and runs the same login-like intent through both stacks.

References and version anchors

• Robot Framework 7.4.2 User Guide — suite/resource/library lifecycle, variable/result behavior, and external-library boundary.
• SeleniumLibrary documentation and SeleniumLibrary 6.9.0 on PyPI — Selenium 4 integration, WebDriver lifecycle, waits, screenshots, and current compatibility.
• Robot Framework Browser documentation, installation, waiting concepts, and logging/tracing — Browser 20.4.0 / Playwright integration.
• Browser 20.4.0 on PyPI — Python and package release anchor.
• DevOps Academy Selenium course — prerequisite browser-testing principles; this chapter focuses on the Robot Framework integration layer.