Show HN: Selenium Boot – Spring Boot's Conventions, Applied to Selenium

mdsddmhossain1 pts0 comments

Selenium Boot — The Spring Boot of Selenium<br>Focus on testing, not framework engineering<br>The Spring Boot of Selenium<br>Zero setup. Smarter defaults. Playwright-inspired APIs. Enterprise-ready automation —without hiding Selenium.<br>Get StartedWhy Selenium Boot

LoginTest.java<br>public class LoginTest extends BaseTest {

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

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

What you get<br>Outcomes first — the API is right there<br>Playwright's best ideas, brought into the Selenium ecosystem. Sensible defaults do the rest.

Never write Thread.sleep() again<br>WaitEngine<br>Every action auto-waits on a centralised engine with 10+ built-in conditions. Flaky timing bugs disappear.

Tests survive CSS & DOM refactors<br>Accessibility-first locators<br>getByRole, getByLabel, getByText, getByTestId — target the accessibility tree, not brittle selectors.

Assertions that don't flake on timing<br>Web-first assertThat()<br>assertThat(locator).isVisible() auto-retries until true or the timeout — no manual polling.

Flaky tests stop failing your build<br>@Retryable + RetryListener<br>Global, per-method, or per-scenario retries. Quarantine known-flaky tests without deleting them.

Hand stakeholders a report they'll read<br>HTML report + JUnit XML<br>Tabbed dashboard — overview, cases, failures, flakiness radar. JUnit XML parsed natively by any CI.

Safe parallel execution by default<br>ThreadLocal DriverManager<br>One driver per thread, isolated and thread-safe. Scale across methods or classes with a config flag.

CI that configures itself<br>CiEnvironmentDetector<br>Auto-detects GitHub Actions / Jenkins / GitLab. Headless forced, threads tuned, pass-rate gates enforced.

Extend it without forking it<br>SPI plugin toolkit<br>Registry-based plugins for custom drivers, hooks, and report adapters. The escape hatch most never need.

See all features →

Before / after<br>Delete the boilerplate, keep the intent<br>No driver setup. No Thread.sleep(). No brittle CSS selectors. Just the test.

✨ Selenium BootRaw Selenium<br>public class LoginTest extends BaseTest {

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

assertThat(getByText("Welcome"))<br>.isVisible(); // web-first, retries<br>// Raw Selenium — you own all of this<br>WebDriver driver = new ChromeDriver();<br>driver.manage().timeouts()<br>.implicitlyWait(Duration.ofSeconds(10));<br>driver.get("https://example.com/login");

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

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

One ecosystem<br>Framework, MCP server, and IDE tooling<br>From a single dependency to AI-assisted, accessibility-first codegen right inside your editor.

Framework<br>io.github.seleniumboot<br>The core Java library<br>One dependency. Extend BaseTest / BasePage and the lifecycle, waits, retries, and reporting are handled.<br>Maven CentralMCP Server<br>pip install<br>AI-powered test authoring<br>Let Claude or Copilot drive a real browser, record a session, and generate framework-native, accessibility-first tests.<br>PyPI · seleniumboot-mcpIntelliJ Plugin<br>IDEA 2024.2+<br>JetBrains Marketplace<br>Spring-Initializr-style New Project wizard, selenium-boot.yml schema completion, and a one-click run config.<br>JetBrains MarketplaceVS Code Extension<br>MCP-ready<br>Visual Studio Marketplace<br>Project scaffolding and MCP integration so codegen stays framework-aware right inside your editor.<br>VS Code Marketplace

Two credible reasons<br>Why Selenium Boot?<br>Whether you're maintaining a home-grown framework or already invested in Selenium.

Why not just build your own?<br>Roll your ownSelenium BootWrite & maintain driver lifecycle, waits, retriesProvided, thread-safe, zero configBuild a reporting layer from scratchHTML report + JUnit XML includedBespoke CI wiring per projectAuto-detects GitHub Actions / Jenkins / GitLabOnboarding = "read our internal wiki"Onboarding = public docs + one dependencyYou fix the bugsThe framework ships the fixes

Already invested in Selenium?<br>Playwright ideaIn Selenium BootAccessibility-first locatorsgetByRole / getByLabel / getByText — survive CSS refactorsAuto-waitingWaitEngine-backed actions — Thread.sleep() disappearsWeb-first assertionsassertThat(...) that auto-retries until trueConvention over configurationZero-boilerplate defaults, optional selenium-boot.yml

Apache-2.0 · Java 17+ · TestNG & JUnit 5Maven Central ↗GitHub ↗PyPI ↗

Keep your test code. Delete the plumbing.<br>Add one dependency and focus on testing — not framework engineering.<br>io.github.seleniumboot selenium-boot<br>Get StartedStar on GitHub

selenium boot framework first driver thread

Related Articles