Focus on testing, not framework engineering

The Spring Boot of Selenium

Name: Selenium Boot
Author: Selenium Boot

One dependency. Sensible defaults. Playwright-inspired APIs. Reports, retries, and CI gates built in —without hiding Selenium.

Get Started Start a project GitHub ↗Why Selenium Boot →

Listed on selenium.dev/ecosystem

LoginTest.java

public class LoginTest extends BaseTest {

    @Test
    public void login() {
        open("/login");
        getByLabel("Username").fill("admin");
        getByRole(Role.BUTTON)
            .withName("Sign in").click();
        assertThat(getByText("Welcome"))
            .isVisible();
    }
}

Every Java team rebuilds the same BaseTest,DriverFactory, and wait utilities.Stop maintaining plumbing.

New · Project generator

Start a project in one minute

Pick Maven or Gradle, TestNG or JUnit 5, and download a working Selenium Boot project. Unzip it, run one command, and watch a real test pass. It's built in your browser — nothing is uploaded.

Generate my project →or use the GitHub template ↗

Build tool

MavenGradle

Runner

TestNGJUnit 5

$ unzip my-project.zip && cd my-project
$ mvn test
Tests run: 1, Failures: 0 — BUILD SUCCESS

Needs Java 17+ and the browser you pick.

What you get

Outcomes first — the API is right there

Playwright's best ideas, brought into the Selenium ecosystem. Sensible defaults do the rest.

Never write Thread.sleep() again

WaitEngine

Every action auto-waits on a centralised engine with 10+ built-in conditions, so fixed sleeps and most timing flakes go away.

Tests survive CSS & DOM refactors

Accessibility-first locators

getByRole, getByLabel, getByText, getByTestId — target the accessibility tree, not brittle selectors.

Assertions that don't flake on timing

Web-first assertThat()

assertThat(locator).isVisible() auto-retries until true or the timeout — no manual polling.

Known-flaky tests stop blocking your build

@Retryable + RetryListener

Global, per-method, or per-scenario retries absorb transient failures. Quarantine known-flaky tests without deleting them.

Hand stakeholders a report they'll read

HTML report + JUnit XML

Tabbed dashboard — overview, cases, failures, flakiness radar. JUnit XML parsed natively by any CI.

Safe parallel execution by default

ThreadLocal DriverManager

One driver per thread, isolated and thread-safe. Scale across methods or classes with a config flag.

CI that configures itself

CiEnvironmentDetector

Auto-detects GitHub Actions / Jenkins / GitLab. Headless forced, threads tuned, pass-rate gates enforced.

Extend it without forking it

SPI plugin toolkit

Registry-based plugins for custom drivers, hooks, and report adapters. The escape hatch most never need.

See all features →

Before / after

Delete the boilerplate, keep the intent

No driver setup. No Thread.sleep(). No brittle CSS selectors. Just the test.

✨ Selenium BootRaw Selenium

public class LoginTest extends BaseTest {

    @Test
    public void login() {
        open("/login");                    // baseUrl from config
        getByLabel("Username").fill("admin");
        getByLabel("Password").fill("secret");
        getByRole(Role.BUTTON)
            .withName("Sign in").click();  // auto-waits

        assertThat(getByText("Welcome"))
            .isVisible();                  // web-first, retries
    }
}

// Raw Selenium — you own all of this
WebDriver driver = new ChromeDriver();
driver.manage().timeouts()
    .implicitlyWait(Duration.ofSeconds(10));
driver.get("https://example.com/login");

Thread.sleep(2000); // hope the page is ready
driver.findElement(
    By.cssSelector("#login-form .btn-primary")).click();

// screenshots, retries, reporting, teardown…
// all your problem
driver.quit();

The same login flow against a real page, written both ways. Both tests pass.

Selenium Boot builds on WebDriver rather than replacing it. It is an independent project — a listing on selenium.dev is not an endorsement by the Selenium project.

One ecosystem

One framework, with tooling around it

Start with the framework. The MCP server, migrator, and IDE plugins are optional extras that build on it.

Framework

io.github.seleniumboot

The core Java library

One dependency. Extend BaseTest / BasePage and the lifecycle, waits, retries, and reporting are handled.

Maven Central

MCP Server

pip install

AI-powered test authoring

Let Claude or Copilot drive a real browser, record a session, and generate framework-native, accessibility-first tests.

PyPI · seleniumboot-mcp

Migrator

CLI

Move an existing Selenium project over

Scan a Selenium Java project, see what maps onto Selenium Boot and what needs a human, and write a migrated copy. Early release.

Learn more

IntelliJ Plugin

IDEA 2024.2+

JetBrains Marketplace

Spring-Initializr-style New Project wizard, selenium-boot.yml schema completion, and a one-click run config.

JetBrains Marketplace

VS Code Extension

MCP-ready

Visual Studio Marketplace

Project scaffolding and MCP integration so codegen stays framework-aware right inside your editor.

VS Code Marketplace

Two credible reasons

Why Selenium Boot?

Whether you're maintaining a home-grown framework or already invested in Selenium.

Why not just build your own?

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

Already invested in Selenium?

Playwright idea	In Selenium Boot
Accessibility-first locators	getByRole / getByLabel / getByText — survive CSS refactors
Auto-waiting	WaitEngine-backed actions — no Thread.sleep() in test code
Web-first assertions	assertThat(...) that auto-retries until true
Convention over configuration	Sensible defaults, optional selenium-boot.yml

Apache-2.0 · Java 17+ · TestNG & JUnit 5Listed on selenium.dev/ecosystem ↗Maven Central ↗GitHub ↗PyPI ↗

FAQ

Common questions

Is Selenium Boot a replacement for Selenium?

No. It is built on WebDriver and never hides it: the raw driver and every Selenium API stay available. Selenium Boot takes over the plumbing around it — driver lifecycle, waits, retries, configuration and reporting.

How does it compare to Playwright?

They are different tools. Playwright is its own automation stack. Selenium Boot is for teams that are staying on Selenium and want ideas like accessibility-first locators, auto-waiting and web-first assertions inside it. It does not try to replace Playwright.

Can I use it with my existing Selenium tests?

Yes. You can add it to an existing project and adopt it test by test. The Migrator (early release) analyzes a project read-only, reports what maps cleanly and what needs a human, and can write a migrated copy without touching your original.

What do I need to run it?

Java 17+, Maven or Gradle, and Chrome or Firefox. Selenium Manager fetches the driver binaries. TestNG and JUnit 5 are both supported.

Do I need the MCP server or the IDE plugins?

No. The framework works on its own. The MCP server, Migrator and IDE plugins are optional extras that build on it.

Is it free?

Yes. It is open source under Apache-2.0. It is an independent project; a listing on selenium.dev is not an endorsement by the Selenium project.

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.8.0</version>
</dependency>

Get Started Star on GitHub

Or start from a working project:use the starter template ↗