Your First Selenium Test in Java, With No Config File

The slowest part of a new Selenium project is rarely the test. It’s everything before the test: the driver setup, the timeouts, the config file, the base class you copy from the last project and hope still works.

Selenium Boot 3.5.0 removes one of those steps. selenium-boot.yml is now optional.

What you need

One dependency:

<dependency>
    <groupId>io.github.seleniumboot</groupId>
    <artifactId>selenium-boot</artifactId>
    <version>3.5.0</version>
    <scope>test</scope>
</dependency>

One test class:

import com.seleniumboot.test.BaseTest;
import org.testng.annotations.Test;

public class SmokeTest extends BaseTest {

    @Test
    public void opensThePage() {
        getDriver().get("https://example.com");
    }
}

Then mvn test. No YAML, no driver download step, no WebDriverManager call.

What happens on the first run

With no selenium-boot.yml in the working directory or on the classpath, the framework starts on built-in defaults and tells you so, once:

[Selenium Boot] No selenium-boot.yml found — running with built-in defaults
(chrome, local, timeouts.explicit=10s, timeouts.pageLoad=30s).
Add a selenium-boot.yml to customise.

That is the whole change in behaviour. Chrome, local execution, a 10-second explicit wait and a 30-second page-load timeout. Any field a file leaves out falls back to the same defaults, so you can add the file later and set only what you want to change.

It does not hide mistakes. If you point -Dselenium.boot.config at a path that doesn’t exist, or ask for a profile with no file, you still get an error. A typo never silently runs on defaults.

The one thing you still need

There is no default base URL, so open() needs one. Without a config file, navigate with getDriver().get(url) as above. When you want open() and open("/login"), add:

execution:
  baseUrl: https://your-app.example.com

If you call open() without it, the error now names the missing key:

execution.baseUrl is not set — add it to selenium-boot.yml,
or navigate with getDriver().get(url)

Why this took two cold-start runs to get right

We found the gap by doing what a stranger would do: a fresh Maven project, the getting-started guide copied step by step, no config file. The first run failed. The docs said the file was optional, but the version they told you to depend on predated the change, so it aborted with “Configuration file not found.”

The second run, on the newer code, exposed a smaller gap. The guide’s sample test used open(), which needs a base URL, so it failed with a message that didn’t say why.

Both are fixed in 3.5.0, and the guide now says which step needs the file. Cold-start runs like these are how we check the docs match the artifact on Maven Central.

Also in 3.5.0

• Locators that wait. click(), type(), getText() and the other terminal Locator actions now look the element up again on every poll, up to timeouts.explicit. A page that re-renders an element between lookup and click no longer surfaces a StaleElementReferenceException. One behaviour change to know about: a locator that matches nothing is now retried for the timeout before it fails, with the same LocatorException as before.
• JUnit 6. junit-jupiter-api and junit-platform-launcher are on 6.1.3. Projects still on JUnit 5.10.2 keep working unchanged; we ran the same 11 real-browser tests against both.

Still Selenium underneath: same WebDriver, same Grid, same locators you already know.

Try it

Start with the getting-started guide, or read the 3.5.0 release notes. If the guide doesn’t work as written, open an issue. That is how the last two got found.