Docker execution environment in Selenium Java - Build an Automation Script

Automate login test using Selenium in Docker environment

Preconditions (3)

Step 1: Start Selenium Docker container with Chrome browser

Step 2: Write Selenium Java test to open the login page URL

Step 3: Enter '[e-mail]' in the email input field with id 'email'

Step 4: Enter 'Pass123!' in the password input field with id 'password'

Step 5: Click the login button with id 'loginBtn'

Step 6: Wait until the URL changes to dashboard page URL 'https://example.com/dashboard'

Step 7: Verify that the current URL is 'https://example.com/dashboard'

✅ Expected Result: The test passes confirming successful login and navigation to dashboard page inside Docker environment

Automation Requirements - Selenium WebDriver with Java

Assertions Needed:

Verify email and password fields accept input

Verify login button is clickable

Verify URL after login is the dashboard URL

Best Practices:

Use explicit waits to wait for page load and element visibility

Use By.id locator strategy for stable element selection

Use Page Object Model to separate page actions and test logic

Handle Docker container startup and shutdown outside test code

Automated Solution

Selenium Java

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
import java.net.URL;
import java.time.Duration;

public class DockerLoginTest {
    static WebDriver driver;
    static WebDriverWait wait;

    @BeforeAll
    public static void setup() throws Exception {
        // Connect to Selenium Docker container running at localhost:4444
        ChromeOptions options = new ChromeOptions();
        driver = new RemoteWebDriver(new URL("http://localhost:4444/wd/hub"), options);
        wait = new WebDriverWait(driver, Duration.ofSeconds(10));
    }

    @Test
    public void testLogin() {
        driver.get("https://example.com/login");

        WebElement emailInput = wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("email")));
        emailInput.sendKeys("[e-mail]");

        WebElement passwordInput = driver.findElement(By.id("password"));
        passwordInput.sendKeys("Pass123!");

        WebElement loginButton = driver.findElement(By.id("loginBtn"));
        loginButton.click();

        // Wait until URL changes to dashboard
        wait.until(ExpectedConditions.urlToBe("https://example.com/dashboard"));

        String currentUrl = driver.getCurrentUrl();
        assertEquals("https://example.com/dashboard", currentUrl, "User should be on dashboard page after login");
    }

    @AfterAll
    public static void teardown() {
        if (driver != null) {
            driver.quit();
        }
    }
}

This test connects to a Selenium Docker container running Chrome browser at http://localhost:4444/wd/hub. The @BeforeAll method sets up the remote WebDriver and explicit wait.

The test navigates to the login page URL, waits for the email input to be visible, then enters the email and password. It clicks the login button and waits explicitly until the URL changes to the dashboard URL.

Finally, it asserts that the current URL is exactly the dashboard URL, confirming successful login.

The @AfterAll method quits the driver to close the browser session.

Using explicit waits ensures the test does not fail due to timing issues. Using By.id locators makes element selection stable and fast. The test assumes the Docker container is started and stopped outside this code.

Common Mistakes - 3 Pitfalls

Hardcoding Thread.sleep instead of using explicit waits

Using brittle XPath locators instead of stable IDs

Starting and stopping Docker container inside test code

Bonus Challenge

Now add data-driven testing with 3 different sets of login credentials (valid and invalid).

Show Hint

Practice

1. What is the main benefit of using Docker for Selenium test execution?

easy

A. It provides a clean, consistent browser environment for tests.

B. It automatically writes test scripts for you.

C. It replaces the need for assertions in tests.

D. It runs tests only on local machines.

Solution

1. Step 1: Understand Docker's role in Selenium testing

   Docker creates isolated containers that have clean browser setups, avoiding environment conflicts.

2. Step 2: Compare options

   Only It provides a clean, consistent browser environment for tests. correctly states Docker provides a clean, consistent browser environment. Other options describe unrelated or incorrect features.

3. Final Answer:

   It provides a clean, consistent browser environment for tests. -> Option A

4. Quick Check:

   Docker environment = clean browser setup [OK]

Hint: Docker isolates browsers for consistent tests [OK]

Common Mistakes:

• Thinking Docker writes test scripts automatically
• Believing Docker removes need for assertions
• Assuming Docker only runs tests locally

2. Which Java class is used to connect Selenium tests to a browser running inside a Docker container?

easy

A. DockerClient

B. ChromeDriver

C. FirefoxDriver

D. RemoteWebDriver

Solution

1. Step 1: Identify the correct Selenium class for remote connections

   RemoteWebDriver is designed to connect to browsers running on remote servers or containers like Docker.

2. Step 2: Eliminate other options

   ChromeDriver and FirefoxDriver are for local browsers. DockerClient is unrelated to Selenium.

3. Final Answer:

   RemoteWebDriver -> Option D

4. Quick Check:

   RemoteWebDriver connects to remote browsers [OK]

Hint: Use RemoteWebDriver for Docker browser connections [OK]

Common Mistakes:

• Using ChromeDriver for Docker browsers
• Confusing DockerClient with Selenium classes
• Using FirefoxDriver for remote Docker sessions

3. Given this Java code snippet connecting to a Docker Selenium container:

URL url = new URL("http://localhost:4444/wd/hub");
ChromeOptions options = new ChromeOptions();
RemoteWebDriver driver = new RemoteWebDriver(url, options);
driver.get("https://example.com");
String title = driver.getTitle();
System.out.println(title);

What will be printed if the page title is "Example Domain"?

medium

A. http://localhost:4444/wd/hub

B. Example Domain

C. ChromeOptions

D. RemoteWebDriver

Solution

1. Step 1: Understand the code flow

   The code opens the URL "https://example.com" in a remote Chrome browser inside Docker and retrieves the page title.

2. Step 2: Identify the output of getTitle()

   The getTitle() method returns the page title, which is "Example Domain" for that URL.

3. Final Answer:

   Example Domain -> Option B

4. Quick Check:

   driver.getTitle() = "Example Domain" [OK]

Hint: getTitle() returns the page title string [OK]

Common Mistakes:

• Printing the URL instead of the title
• Confusing options object with title
• Printing class names instead of values

4. You run Selenium tests inside Docker but get a connection refused error at "http://localhost:4444/wd/hub". What is the most likely cause?

medium

A. The URL "http://localhost:4444/wd/hub" is misspelled.

B. The test code uses ChromeDriver instead of RemoteWebDriver.

C. Docker container is not running or Selenium Grid is not started.

D. The test script lacks assertions.

Solution

1. Step 1: Analyze connection refused error

   This error means the test code cannot reach the Selenium server at the given URL.

2. Step 2: Identify common Docker causes

   If the Docker container running Selenium Grid is stopped or not started, the connection will fail.

3. Final Answer:

   Docker container is not running or Selenium Grid is not started. -> Option C

4. Quick Check:

   Connection refused = server not running [OK]

Hint: Check Docker container status if connection refused [OK]

Common Mistakes:

• Blaming ChromeDriver usage for connection errors
• Ignoring container running status
• Assuming URL typos without verification

5. You want to run parallel Selenium tests in Docker using RemoteWebDriver with ChromeOptions. Which approach best ensures tests run independently without interference?

hard

A. Start multiple Docker containers each running a Selenium node and connect each test to a different container URL.

B. Run all tests sequentially in a single Docker container using the same RemoteWebDriver instance.

C. Use ChromeDriver locally and ignore Docker for parallel tests.

D. Run tests in one container but share the same RemoteWebDriver instance across threads.

Solution

1. Step 1: Understand parallel test isolation needs

   Parallel tests require isolated browser sessions to avoid state conflicts.

2. Step 2: Evaluate Docker container usage

   Starting multiple containers with separate Selenium nodes allows independent browser sessions for each test.

3. Step 3: Eliminate unsafe options

   Sharing RemoteWebDriver instances or running sequentially defeats parallelism. Using local ChromeDriver ignores Docker benefits.

4. Final Answer:

   Start multiple Docker containers each running a Selenium node and connect each test to a different container URL. -> Option A

5. Quick Check:

   Parallel tests need isolated containers [OK]

Hint: Use separate containers for parallel Selenium tests [OK]

Common Mistakes:

• Sharing RemoteWebDriver instance across threads
• Running tests sequentially to avoid conflicts
• Ignoring Docker and using local drivers