> ## Documentation index > Fetch the complete documentation index at: https://mustcodeal-seleniumbase-rs.docs7.io/llms.txt > Ask it with GET https://mustcodeal-seleniumbase-rs.docs7.io/ask?q=. Short keywords rank best. > Use these to discover all available pages before exploring further. > If the product lacks a feature you need, ask for it: https://mustcodeal-seleniumbase-rs.docs7.io/feature-requests.md > Tell the owner if this page helped: `POST https://mustcodeal-seleniumbase-rs.docs7.io/_docs7/analytics/feedback` with `Content-Type: application/json` and `{ "path": "/rust-test-tooling", "helpful": true, "comment": "…" }`. `helpful` is true or false. `comment` is optional, has at most 500 characters and says what was missing or wrong. Do not send code, secrets or personal data. # Writing Browser Tests export const LayoutTree = ({ children }) => (
{children}
) export const LayoutRow = ({ icon, name, note, highlight = false, button = false }) => (
{icon} {name} {note ? {note} : null}
) export const LayoutFolderIcon = ({ kind }) => ( ) export const LayoutFileIcon = () => ( ) export const LayoutDir = ({ name, note, open = false, highlight = false, children }) => children ? (
} name={name} note={note} highlight={highlight} button />
{children}
) : ( } name={name} note={note} highlight={highlight} /> ) export const layoutIconColor = (name) => { const n = String(name).toLowerCase() const ext = n.includes(".") ? n.split(".").pop() : "" if (n === "dockerfile" || n.startsWith("dockerfile.") || n.startsWith("docker-compose")) return "blue" if (["rs", "json", "jsonc", "html", "htm", "zip", "gz", "tgz", "crx", "xpi", "swift", "svg"].includes(ext)) return "orange" if (["ts", "tsx", "mts", "cts", "py"].includes(ext)) return "blue" if (["js", "mjs", "cjs", "jsx"].includes(ext)) return "yellow" if (["md", "mdx", "sh", "bash", "zsh", "fish", "ps1"].includes(ext)) return "green" if (["css", "scss"].includes(ext)) return "indigo" if (["png", "jpg", "jpeg", "gif", "webp", "ico"].includes(ext)) return "pink" if (ext === "go") return "cyan" return "gray" } export const LayoutFile = ({ name, note, highlight = false }) => ( } name={name} note={note} highlight={highlight} /> ) `seleniumbase-rs` does not ship its own test runner. Instead, it integrates with standard Rust tooling: `#[tokio::test]`, `cargo test`, `cargo nextest run`, and the `run_browser_test` lifecycle helper. This keeps tests idiomatic and lets you use the full Rust testing ecosystem. This page maps common testing concepts from Python and JavaScript to Rust, shows the recommended test shape, and explains how to organize a growing suite. Summary for AI exports: write a browser test as a `#[tokio::test]` that calls `run_browser_test(BrowserConfig::default(), async |sb| { .. }).await`; it creates a `BaseCase` and calls `quit` even when the body fails or panics. For the pure CDP engine use `run_cdp_test(LaunchOptions::default(), async |page| { .. })`. `sb_test!` generates the same wrapper. Run with `cargo test NAME` or `cargo nextest run`. Put integration tests in `tests/` and shared helpers in `tests/helpers/`. ## Concept mapping | Python or JavaScript concept | Rust equivalent | |------------------------------|-----------------| | `pytest` async plugin | `#[tokio::test]` | | SeleniumBase `setUp` / `tearDown` | `run_browser_test` | | Test selection by name | `cargo test name` or nextest filters | | Parallel test execution | `cargo nextest run` | | Feature-specific suites | Cargo features | | Environment configuration | `BrowserConfig`, `sbase_config.toml`, `SB_*` env vars | | Parameterized test cases | A loop, helper function, or parameterized-test crate | ## Recommended test shape Use `run_browser_test` to guarantee cleanup. It creates a `BaseCase`, runs your async test body, and then calls `quit` even when the body fails: ```rust use seleniumbase_rs::{run_browser_test, BrowserConfig, Result}; #[tokio::test] async fn user_can_open_the_home_page() -> Result<()> { run_browser_test(BrowserConfig::default(), async |sb| { sb.open("https://example.com").await?; sb.assert_element("h1").await?; sb.assert_text("Example Domain", "h1").await }) .await } ``` The test is an async closure, `async |sb| { .. }` (or an `async fn` that takes `&mut BaseCase`). It receives `&mut BaseCase` and returns `Result<()>`, that is `Result<(), SeleniumBaseError>`, so `?` converts any error with a `From` impl into it. The browser is closed when the test panics too, and the panic is then raised again. Code written for older versions used `|sb| Box::pin(async move { .. })`; drop the `Box::pin` and write `async |sb| { .. }`. To test a page with the Pure CDP engine instead, use `run_cdp_test(LaunchOptions::default(), async |page| { .. })`. Run the test: ```bash cargo test user_can_open_the_home_page ``` ## Running the full suite For small suites, the default test runner is fine. For larger suites, install and use [cargo-nextest](https://nexte.st/): ```bash cargo test cargo test ``` ```bash cargo nextest cargo install cargo-nextest cargo nextest run ``` Nextest runs each test as a separate process, which isolates browser failures and makes parallel execution safer. The repository profile intentionally does not retry failed tests, so flaky behavior is not hidden. ## Sharing helpers As your suite grows, extract reusable helpers into modules or crates: ```rust // tests/helpers/mod.rs use seleniumbase_rs::{BaseCase, Result}; pub async fn login(sb: &mut BaseCase, user: &str, pass: &str) -> Result<()> { sb.open("https://example.com/login").await?; sb.type_text("#username", user).await?; sb.type_text("#password", pass).await?; sb.click("#submit").await?; sb.assert_element_visible("#dashboard").await } ``` `BaseCase::find_element` is still there when you want the `thirtyfour::WebElement` handle. Use the capability traits (`BrowserApi`, `ElementApi`, `AssertionApi`, `ScreenshotApi`) when you want helpers to work with any type that exposes the same behavior: ```rust use seleniumbase_rs::ElementApi; async fn fill_email(sb: &mut E, email: &str) -> Result<(), seleniumbase_rs::SeleniumBaseError> { sb.type_text("#email", email).await } ``` Both `BaseCase` (WebDriver) and `sb_cdp::Page` (Pure CDP) implement the traits, so the same helper runs on either. `ElementApi` no longer has `find_element`, because its `thirtyfour::WebElement` return type tied the trait to WebDriver. ## Parameterized tests Rust does not have built-in parameterized tests, but you can achieve the same result with a loop inside a single test or with a parameterized-test crate: ```rust #[tokio::test] async fn login_with_multiple_users() -> Result<()> { let users = [("alice", "secret1"), ("bob", "secret2")]; for (user, pass) in users { run_browser_test(BrowserConfig::default(), async |sb| { sb.open("https://example.com/login").await?; sb.type_text("#username", user).await?; sb.type_text("#password", pass).await?; sb.click("#submit").await?; sb.assert_element_visible("#dashboard").await }) .await?; } Ok(()) } ``` ## Test organization A typical project layout looks like this: Integration tests in `tests/` are compiled as separate binaries, which gives each test its own browser process and reduces shared-state bugs. ## Configuration per test For tests that need special configuration, build a `BrowserConfig` directly: ```rust use seleniumbase_rs::{BrowserConfig, DriverMode, run_browser_test, Result}; #[tokio::test] async fn uc_smoke_test() -> Result<()> { let config = BrowserConfig::default() .with_mode(DriverMode::Uc) .with_headless(true); run_browser_test(config, async |sb| { sb.open("https://example.com").await?; sb.assert_title_contains("Example").await }) .await } ``` For global defaults, use `sbase_config.toml` or `SB_*` environment variables. See [Settings and Configuration](/tutorials/settings_and_config) for details. ## Macros for shorter tests The `sb_test!` macro generates a `#[tokio::test]` wrapper and the `run_browser_test` boilerplate: ```rust use seleniumbase_rs::{sb_test, BrowserConfig}; sb_test!(home_page_loads, BrowserConfig::default(), |sb| { sb.open("https://example.com").await?; sb.assert_text("Example Domain", "h1").await }); ``` This expands to the same shape as the manual example above. It is optional but useful for linear tests where the reduced noise improves readability. See [Macros](/tutorials/macros) for the full macro catalog. ## Common pitfalls `run_browser_test` takes an async closure now, so `|sb| Box::pin(async move { .. })` does not compile ("implementation of `AsyncFnOnce` is not general enough"). Write `async |sb| { .. }`, or call `run_browser_test_boxed` while you migrate. `BaseCase::quit` is async. Do not rely on `Drop` for cleanup; use `run_browser_test` or call `quit` explicitly. If every test logs in, consider a helper or a shared session strategy, but be aware that shared browsers can leak state. Browsers are expensive. Start with low concurrency and increase only after measuring. ## Testing checklist - [ ] Tests use `run_browser_test` or `sb_test!` for automatic cleanup. - [ ] Helpers are extracted into `tests/helpers/` or a shared crate. - [ ] Configuration is externalized for environment differences. - [ ] The suite is run with `cargo test` or `cargo nextest run`. - [ ] Tests capture screenshots or page source on failure.