Project Setup with Maven

Real Selenium projects are almost never a single loose .java file — they're managed with Maven, a build tool that handles two things for us: downloading the selenium-java library (and its dependencies) automatically, and giving the project a standard, predictable folder structure that any teammate (or CI server) can build without guessing.

Creating the Project

In IntelliJ IDEA or Eclipse: File → New → Project → Maven, choose a groupId like com.recipebox.tests and an artifactId like recipebox-automation. Maven creates a pom.xml file at the project root — this file is the entire configuration of the project: what libraries it depends on, what Java version it compiles against, and how tests are run.

The pom.xml Dependencies

Add the Selenium Java bindings as a dependency. We'll add TestNG in a later lesson once we start writing structured test classes — for now, this is all pom.xml needs:

<project xmlns="http://maven.apache.org/POM/4.0.0">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.recipebox.tests</groupId>
    <artifactId>recipebox-automation</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>4.21.0</version>
        </dependency>
    </dependencies>
</project>
Note: selenium-java is an aggregator dependency — adding it pulls in everything you need: the core WebDriver API, the Chrome/Firefox/Edge driver bindings, and Selenium Manager (covered next). You don't need to add those separately.

Selenium Manager: No More Manual Driver Downloads

In older Selenium versions (3.x and early 4.x), you had to manually download chromedriver.exe, put it somewhere on disk, and either add it to your system PATH or point to it with System.setProperty("webdriver.chrome.driver", "..."). This broke constantly — every time Chrome auto-updated, the driver version could go out of sync and your tests would fail with a version-mismatch error.

Starting with Selenium 4.6, a built-in tool called Selenium Manager handles this for you automatically. When your code calls new ChromeDriver(), Selenium Manager:

  • Detects which browser (and version) is installed on your machine.
  • Downloads a matching driver binary if one isn't already cached locally.
  • Wires it up transparently — no PATH configuration, no System.setProperty calls needed for the common case.
In practice: as long as you're on Selenium 4.6+ and a supported browser is installed, new ChromeDriver(); just works. You'll still see teams manually manage driver binaries in locked-down corporate environments without internet access, but for local development and most CI setups, Selenium Manager removes an entire category of setup pain.

Standard Project Folder Structure

Maven expects a specific layout, and Selenium test code goes under the test tree since it's test code, not production application code:

recipebox-automation/
├── pom.xml
├── src/
│   ├── main/
│   │   └── java/              // (empty for a pure test project)
│   └── test/
│       └── java/
│           └── com/
│               └── recipebox/
│                   └── tests/
│                       └── FirstTest.java
Note: Keeping test code under src/test/java (rather than src/main/java) matters once you introduce TestNG or JUnit — Maven's mvn test goal specifically looks for tests there, and it keeps your test dependencies separate from any production code in the same repository.
Next up: the project is set up — time to write and actually run a real Selenium script against RecipeBox's login page. Head to Your First Selenium Script.