Checkpoint Lab — SeleniumLibrary and Browser Automation Integration

1. Safety and scope rules

• Target only http://127.0.0.1:8765/ (or another documented loopback port).
• Use only fake credentials demo/mode.
• Mandatory completion requires at least one supported local browser library path to actually run.
• If the second stack cannot run on the machine, provide a documented simulation/import review and state the missing prerequisite; do not claim its browser behavior was verified.
• Do not kill all browser/driver/Node processes. Close only library-owned state.
• Preserve failing output, screenshot/trace, exact command, and versions before repair.

2. Exact preflight

python --version
python -m robot --version
python -m pip show robotframework-seleniumlibrary selenium robotframework-browser robotframework-browser-batteries
# If Browser is installed:
rfbrowser --version
# Verify local AUT:
python -c "import urllib.request; print(urllib.request.urlopen('http://127.0.0.1:8765/', timeout=2).status)"

Record the output. For SeleniumLibrary, confirm an installed supported browser. For Browser, confirm either a Playwright browser binary or an explicitly documented installed Chromium channel. No real external endpoint is allowed.

3. Build the project

Use the same app/index.html, Selenium resource, Browser resource, and two suites from Lesson 2. Keep the two library implementations separate. Your dependency direction must be test → one domain resource → one browser library.

rf-browser-checkpoint/
├── app/index.html
├── resources/login_selenium.resource
├── resources/login_browser.resource
├── tests/selenium_login.robot
├── tests/browser_login.robot
└── results/

4. Write predictions before execution

Add at least two of your own predictions—for example expected screenshot path or trace creation—and verify them independently.

5. Run the primary supported stack

If SeleniumLibrary is available and Chrome is installed:

python -m robot --outputdir results/selenium tests/selenium_login.robot

If Browser is your primary supported stack:

python -m robot --outputdir results/browser tests/browser_login.robot

Verify the exact test name, PASS status, domain-keyword hierarchy, URL/text assertion, screenshot, and teardown keyword. A green console alone is not sufficient.

6. Compare the second stack

When both stacks are available, run both and compare evidence. If one is unavailable, perform the following non-destructive fallback:

python -m robot --dryrun --outputdir results/dryrun tests/selenium_login.robot
# or the Browser suite if that is the unavailable runtime

A dry run can validate Robot parsing/import/keyword availability when dependencies are installed, but it does not prove browser runtime behavior. If the library itself is missing, inspect the resource and record the exact missing package/runtime prerequisite instead of installing random unpinned dependencies.

7. Inject a locator failure

In the primary resource only, change the submit selector to a nonexistent value. Keep all other code unchanged.

# SeleniumLibrary broken locator
css:[data-testid="submit-missing"]

# Browser broken locator
[data-testid="submit-missing"]

Before running, predict: inputs succeed, click fails after a bounded timeout, the test status is FAIL, teardown still runs, and the first-failure evidence contains the missing selector. Run only the affected test into a new results/failure-* directory. Do not overwrite the passing run.

8. Capture browser-specific evidence

For SeleniumLibrary, inspect the Robot log and screenshot. If the click fails before your explicit screenshot step, you may configure/retain SeleniumLibrary’s failure screenshot behavior according to your project policy; do not expose real values.

For Browser, a controlled diagnostic run can enable trace:

# PowerShell
$env:ROBOT_FRAMEWORK_BROWSER_TRACING = 'True'
python -m robot --outputdir results/failure-browser tests/browser_login.robot
Remove-Item Env:ROBOT_FRAMEWORK_BROWSER_TRACING

# Bash
# ROBOT_FRAMEWORK_BROWSER_TRACING=True python -m robot --outputdir results/failure-browser tests/browser_login.robot

Record the trace path and treat the archive as sensitive. Do not upload it to a public service when it contains non-public application data.

9. Repair the least destructive layer

Restore only the correct selector in the resource. Do not add a sleep, giant timeout, retry wrapper, broad TRY/EXCEPT, or process kill. Rerun the single affected test into a new results directory. Compare the failing and repaired call hierarchy.

10. Timing reasoning exercise

Increase the app’s synthetic delay from 350 ms to 1200 ms. Predict whether each existing path still passes. SeleniumLibrary has a 5-second explicit text wait; Browser has a 5-second Browser timeout/assertion configuration. Verify the primary path. Then set the synthetic delay beyond the bounded timeout and confirm it fails rather than waiting forever. Restore the original delay afterwards.

11. Required evidence packet

12. Verification checklist

• The local AUT is reachable only via loopback.
• At least one browser stack actually executed end to end.
• The second stack was executed or honestly documented as unavailable/simulated.
• No Sleep is required for synchronization.
• The browser state is isolated and cleanup is explicit.
• The failure run is retained separately from the repair run.
• The missing-locator root cause is visible in Robot/browser evidence.
• No real credential, customer data, public API, browser cloud, or production site was used.

13. Cleanup / rollback

1. Stop the specific Python HTTP server with Ctrl+C.
2. Confirm the Robot teardown closed owned browser state.
3. Keep evidence until review is complete.
4. Delete only the disposable project directory if desired.
5. If removing Browser binaries, use the library’s documented rfbrowser clean-node procedure rather than deleting arbitrary runtime folders.

Knowledge check

14. Production operating model and Chapter 17 bridge

After this checkpoint, the Robot platform can own browser automation without confusing Robot state with browser state. Tests express domain intent; resources contain locators and synchronization; one browser library owns engine calls; teardown owns the created session/context; output.xml/log plus browser artifacts preserve evidence. Chapter 17 moves the same discipline down a layer to HTTP/API automation, where HTTP sessions, request/response data, server fixture state, and JSON assertions replace browser state.

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.