Why Selenium Boot
Keep your test code. Delete the plumbing.
Selenium Boot lets teams focus on testing, not framework engineering — without abandoning Selenium, your Grid, or your team's skills.
The strongest frame
Why not just build your own framework?
Almost every Java team already has one: a home-grown BaseTest, a DriverFactory, a pile of wait utilities, and a reporting hack — rewritten from scratch at each new project. It's unpaid infrastructure you own, debug, and maintain forever, rarely tested or parallel-safe.
| Roll your own | Selenium Boot |
|---|---|
| Write & maintain driver lifecycle, waits, retries | Provided, thread-safe, zero config |
| Build a reporting layer from scratch | HTML report + JUnit XML included |
| Bespoke CI wiring per project | Auto-detects GitHub Actions / Jenkins / GitLab |
| Onboarding = "read our internal wiki" | Onboarding = public docs + one dependency |
| You fix the bugs | The framework ships the fixes |
Selenium Boot is that framework — already built, maintained, tested, thread-safe, and documented. You keep the part that's actually yours (the test intent) and delete the rest.
Non-combative by design
Already invested in Selenium?
You don't have to abandon Selenium to get the ergonomics people love in Playwright. Selenium Boot brings those ideas into the Selenium ecosystem — so you keep your stack, your Grid, and your team's skills.
| Playwright idea | In Selenium Boot |
|---|---|
| Accessibility-first locators | getByRole / getByLabel / getByText — survive CSS refactors |
| Auto-waiting | WaitEngine-backed actions — Thread.sleep() disappears |
| Web-first assertions | assertThat(...) that auto-retries until true |
| Convention over configuration | Zero-boilerplate defaults, optional selenium-boot.yml |
…all without hiding raw Selenium. This is not a Playwright replacement — its architecture is genuinely different. It's the best of both, inside the ecosystem you already run.
Layered, not equal parts
The design philosophy
People ask whether it's an opinionated framework, an extensible toolkit, or a thin layer over Selenium. The answer is layered.
Opinionated core
Convention over configuration, zero boilerplate by default. Add one dependency, extend BaseTest / BasePage, and the sensible decisions are already made. selenium-boot.yml is optional.
Never hides Selenium
Unlike heavier abstractions, Selenium Boot never takes the raw WebDriver away. When the conventions don’t fit, drop straight down to WebDriver / By / WebElement. Opinionated without being a cage.
Extensible toolkit
An SPI/registry plugin system makes it modular for power users who need it — serving the opinionated core, not replacing it. Most users never touch it.
Keep your test code. Delete the plumbing.
Add one dependency and focus on testing — not framework engineering.
<dependency>
<groupId>io.github.seleniumboot</groupId>
<artifactId>selenium-boot</artifactId>
<version>3.3.0</version>
</dependency>