Skip to main content

Why Selenium Boot?

Developers adopt a philosophy before they adopt an API. This page is the philosophy.

Selenium Boot is the Spring Boot of Selenium — zero setup, smarter defaults, Playwright-inspired APIs, and enterprise features, without hiding Selenium.

Selenium is powerful and everywhere, but it's deliberately low-level: it gives you a WebDriver and gets out of the way. Everything else — driver lifecycle, waits, retries, reporting, CI wiring — is left to you. Every team ends up rebuilding the same scaffolding. Selenium Boot is that scaffolding, done once, properly.

The idea in three layers​

Selenium Boot is opinionated, but not a cage. The design is layered, not equal parts:

  1. Opinionated core (primary). Convention over configuration, zero boilerplate by default. Add one dependency, extend BaseTest / BasePage, and the framework has already made the sensible decisions — driver lifecycle, waits, retries, reporting, CI wiring. selenium-boot.yml is optional; sensible defaults cover you if you never write it.
  2. Never hides Selenium (the constraint). Unlike heavier abstractions, Selenium Boot never takes the raw WebDriver away from you. When the conventions don't fit, drop straight to WebDriver / By / WebElement. Opinionated without being a cage.
  3. Extensible toolkit (the escape hatch). An SPI/registry plugin system makes it modular for power users — custom drivers, report adapters, lifecycle hooks. Most users never touch it.

What you get for one dependency​

Outcomes first — with the API that delivers them:

OutcomeHow
Never write Thread.sleep() againAuto-waiting locators + WaitEngine
Tests survive CSS refactorsAccessibility-first locators — getByRole, getByLabel, getByText
Flaky tests recover automatically@Retryable + one config line — no IRetryAnalyzer wiring
See exactly why a test failedScreenshot auto-captured on failure, embedded in the HTML report
No WebDriver binaries to manageSelenium Manager resolves drivers automatically
Parallel-safe out of the boxThreadLocal driver isolation — parallel execution
Extend it without forking itJava SPI plugins for drivers, reports, hooks

Who it's for​

  • Teams already invested in Selenium who want Playwright-style ergonomics without leaving the Selenium / Java / TestNG stack, their team's skills, or Selenium Grid.
  • Teams maintaining a home-grown framework — a BaseTest, a DriverFactory, a pile of wait utilities — who'd rather delete that plumbing than keep debugging it.

The two "why" questions those teams actually ask each have their own page:

Next steps​