BaseCase is the main entry point for writing browser automation in
seleniumbase-rs. It wraps a WebDriver/CDP session, provides a fluent API for
navigation, interaction, waits, assertions, and exposes advanced helpers for
stealth, CDP, tours, and screenshots.
This page is a high-level reference. For exact signatures and generic bounds, build the rustdocs with:
What you will learn
- The lifecycle methods for creating and closing sessions.
- Common navigation, interaction, and query methods.
- Wait and assertion patterns.
- Script execution, scrolling, file handling, and advanced interactions.
- CDP/UC helpers and when to use them.
- The capability traits (
BrowserApi,ElementApi,AssertionApi,ScreenshotApi) that both engines implement. - The public items re-exported at the crate root and what each is for.
- Where to find rustdocs for deeper detail.
Reading this page#
The tables list each method as name(arguments), without the sb. in front
and the .await? after. So the row set_attribute(selector, attr, value)
stands for a call like this:
Common arguments#
The same names mean the same thing in every table. The signatures sometimes
use a longer name (css for selector, timeout_secs for timeout).
| Argument | Type | What it is |
|---|---|---|
selector (also src, dst, container) | &str | Which element to act on, as CSS, XPath or link text (see Selector syntax). The first match is used. |
text, expected | &str | Text to type, or the text an assertion expects. assert_text(text, selector) takes the text first. |
attr, prop | &str | An attribute or property name, such as "href" or "value". |
value | &str | The value to set: of an attribute, a field or a storage item. |
url | &str | A full URL, such as "https://example.com/login". |
timeout, timeout_secs | u64 | How many seconds to wait before failing. A method that takes a Duration says so in its signature. |
seconds | f64 | A pause, as in sleep(1.5). |
x, y | integer | A position in pixels (i32 or i64, depending on the method). |
path, filename | &str or &Path | A file to read or write. |
index | usize | A position in a list, such as an <option> of a <select>. |
key | &str | A storage key (get_local_storage_item(key)) or a key name (gui_press_key(key)). |
name | &str | A name the method looks up: a cookie, a tour, a chart, a saved baseline. |
script | &str | JavaScript to run in the page. |
Selector syntax#
A selector string picks its own lookup strategy, as SeleniumBase does:
| Selector starts with | Strategy | Example |
|---|---|---|
| anything else | CSS (the default) | "#submit", "form input[name=q]" |
/, ./, ../, (, or an axis such as parent:: | XPath | "//button[text()='Go']", "(//a)[2]" |
link=, link_text=, text= | Link text (exact) | "link=Sign in" |
partial_link_text=, partial_link=, partial_text=, p_link_text=, p_link=, p_text= | Link text (contains) | "p_text=Sign" |
The prefixes are case-sensitive (LINK=Home is CSS). More in the
Selectors guide.
What methods return#
Almost every method returns seleniumbase_rs::Result<T>, so a test ends each
call with ? (sleep is an exception: it cannot fail).
| Kind of method | Returns |
|---|---|
Actions (click, type_text, open, set_attribute, …) and assertions | (): nothing, or an error |
get_text, get_title, get_current_url and the like | String |
get_attribute(selector, attr), get_property(selector, prop) | Option<String>: None when it is not set |
find_element(selector) | an element: a thirtyfour::WebElement handle to the first match, found within 10 seconds |
find_elements(selector) | Vec<thirtyfour::WebElement>: every match, possibly none |
execute_script(script) | serde_json::Value: what the script returned |
save_screenshot(filename) | PathBuf: where the file was written |
An element handle is the WebDriver engine’s own type. Keep the selector
instead when you can: the BaseCase methods look the element up again on each
call, so they do not go stale when the page re-renders. The pure CDP engine’s
Locator (from page.locator(selector)) is lazy in the same way.
Reference pages#
Create and close a BaseCase session, open pages and move through history.
Click, type, select, hover, drag, press keys and scroll.
Wait for elements and text, assert on the page, and collect deferred assertions.
Read text, attributes, properties, counts and page state.
Switch windows, tabs and frames, and drive several browsers.
Read and write cookies, local storage and session storage.
Take screenshots, run JavaScript and change the DOM.
Download and upload files and work with PDFs.
Chrome DevTools and undetected-mode helpers, including the GUI bypass helpers.
Handle JavaScript dialogs and generate TOTP codes.
Tours, presentations, charts, the recorder and other helpers.
BrowserApi, ElementApi, AssertionApi and ScreenshotApi, shared by both engines.
What seleniumbase_rs re-exports at its root and what each item is for.
Common error handling pattern#
Most BaseCase methods return Result<T, SeleniumBaseError>. Use ? inside an
async function or the sb_test! macro:
Further reading#
CSS, XPath, link text and shadow DOM: how a selector string is read.
Wait for the page, then check it, without sleeps.
The CDP helpers on BaseCase, raw commands and the network reactor.
Run Chrome so sites see a person’s browser.
Convenience macros from the crate root.
Native OS input instead of WebDriver.
For exact signatures, run cargo doc --no-deps --open.
Checked against the source of this branch: the argument lists and argument order of the BaseCase tables (names and counts, by script), the capability traits and the crate-root items. The multi-driver rows (get_new_driver to driver_count) were checked earlier, against commit 8e9180f. The one-line descriptions of the other BaseCase methods were not all re-read.