Docker Selenium Grid in Selenium Java - Framework Patterns

Framework Mode - Docker Selenium Grid

Folder Structure

selenium-grid-project/
├── src/
│   └── test/
│       └── java/
│           ├── pages/
│           │   └── LoginPage.java
│           ├── tests/
│           │   └── LoginTest.java
│           └── utils/
│               └── WebDriverFactory.java
├── docker/
│   ├── docker-compose.yml
│   └── grid-config/
│       └── custom-config.toml
├── resources/
│   └── testdata/
│       └── users.csv
├── testng.xml
└── README.md

Test Framework Layers

• Driver Layer: WebDriverFactory.java manages remote WebDriver instances connecting to Selenium Grid via Docker.
• Page Objects: Classes in pages/ represent UI pages with methods to interact with elements.
• Test Layer: Test classes in tests/ contain test methods using TestNG framework.
• Utilities: Helper classes for reading test data, logging, and WebDriver setup.
• Docker Layer: docker-compose.yml defines Selenium Grid Hub and Nodes containers for parallel browser execution.
• Configuration: testng.xml and property files manage test suites and environment variables.

Configuration Patterns

• Docker Compose: docker/docker-compose.yml configures Selenium Hub and browser nodes (Chrome, Firefox) with network settings.
• Environment Variables: Use Java system properties or TestNG parameters to select browser type and grid URL at runtime.
• Credentials & Secrets: Store sensitive data outside source code, e.g., environment variables or encrypted files.
• TestNG XML: Defines test groups, parallel execution, and parameters for flexible test runs.
• WebDriverFactory: Reads config to create RemoteWebDriver instances pointing to Selenium Grid hub URL.

Test Reporting and CI/CD Integration

• TestNG Reports: Default HTML and XML reports generated after test execution.
• Allure Reporting: Integrate Allure for detailed, user-friendly test reports with screenshots and logs.
• CI/CD Pipelines: Use Jenkins, GitHub Actions, or GitLab CI to start Docker Selenium Grid, run tests, and publish reports automatically.
• Docker Cleanup: Pipeline scripts should start and stop Selenium Grid containers cleanly to avoid resource leaks.
• Parallel Execution: Configure TestNG and Selenium Grid to run tests in parallel for faster feedback.

Best Practices

1. Use Page Object Model: Keep UI interactions separate from test logic for maintainability.
2. Isolate Tests: Each test should create and quit its own WebDriver session to avoid state leaks.
3. Parameterize Browsers: Run tests on multiple browsers by passing parameters, leveraging Selenium Grid's parallel nodes.
4. Explicit Waits: Use explicit waits instead of implicit waits to handle dynamic page elements reliably.
5. Version Control Docker Files: Keep Docker compose and config files under version control for reproducibility.

Self Check

Where in this folder structure would you add a new page object class for the "Dashboard" page?

Key Result

Use Docker Selenium Grid with Page Object Model and TestNG for scalable, parallel browser testing.

Practice

1. What is the main purpose of using Docker Selenium Grid in automated testing?

easy

A. To debug Java code in Selenium tests

B. To write test scripts faster

C. To replace Selenium WebDriver completely

D. To run tests on multiple browsers and machines simultaneously

Solution

1. Step 1: Understand Docker Selenium Grid's role

   Docker Selenium Grid allows running tests on different browsers and machines at the same time, improving test coverage and speed.

2. Step 2: Compare options with this purpose

   Only To run tests on multiple browsers and machines simultaneously matches this main purpose. Options B, C, and D describe unrelated or incorrect uses.

3. Final Answer:

   To run tests on multiple browsers and machines simultaneously -> Option D

4. Quick Check:

   Purpose = run tests on many browsers [OK]

Hint: Docker Selenium Grid = run tests on many browsers [OK]

Common Mistakes:

• Thinking it speeds up writing tests
• Confusing it with Selenium WebDriver itself
• Assuming it is for debugging code

2. Which Docker command correctly starts a Selenium Grid Hub container?

easy

A. docker start selenium/node-chrome

B. docker build -t selenium/hub .

C. docker run -d -p 4444:4444 selenium/hub

D. docker stop selenium/hub

Solution

1. Step 1: Identify the command to run a container

   The command to start a container in detached mode and map port 4444 is 'docker run -d -p 4444:4444 selenium/hub'.

2. Step 2: Check other options

   docker start selenium/node-chrome starts an existing container, C builds an image, and D stops a container. Only B starts the hub container correctly.

3. Final Answer:

   docker run -d -p 4444:4444 selenium/hub -> Option C

4. Quick Check:

   Start hub = docker run -d -p 4444:4444 selenium/hub [OK]

Hint: Use 'docker run -d -p 4444:4444 selenium/hub' to start hub [OK]

Common Mistakes:

• Using 'docker start' instead of 'docker run' to create container
• Confusing build and run commands
• Stopping instead of starting the container

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

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

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

medium

A. Example Domain

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

C. null

D. NoSuchSessionException

Solution

1. Step 1: Understand RemoteWebDriver usage

   The code creates a RemoteWebDriver connected to the Selenium Grid hub URL and opens the page https://example.com.

2. Step 2: Check what driver.getTitle() returns

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

3. Final Answer:

   Example Domain -> Option A

4. Quick Check:

   driver.getTitle() = page title [OK]

Hint: driver.getTitle() prints page title loaded [OK]

Common Mistakes:

• Confusing URL with page title
• Expecting null if no errors
• Assuming exceptions without errors

4. You run this command to start a Chrome node:

docker run -d --link selenium-hub:hub selenium/node-chrome

But your tests fail to connect to the node. What is the likely problem?

medium

A. The Docker daemon is stopped

B. The node container is not linked properly to the hub

C. The Chrome browser is not installed inside the node container

D. The hub container is not running

Solution

1. Step 1: Analyze the linking option

   The '--link' option is deprecated and may not correctly link the node to the hub, causing connection failure.

2. Step 2: Check other possible causes

   Docker daemon (A) or hub not running (B) issues would cause broader failures. Chrome is preinstalled in official node images (C) so unlikely cause.

3. Final Answer:

   The node container is not linked properly to the hub -> Option B

4. Quick Check:

   Deprecated --link causes node-hub connection fail [OK]

Hint: Avoid deprecated --link; use network for node-hub [OK]

Common Mistakes:

• Assuming Chrome is missing inside node container
• Ignoring hub container status
• Not checking Docker daemon status

5. You want to run tests on Chrome and Firefox browsers simultaneously using Docker Selenium Grid. Which setup is correct?

hard

A. Start hub container, then start both selenium/node-chrome and selenium/node-firefox containers connected to the hub network

B. Start only selenium/node-chrome container; Firefox tests will run on Chrome node

C. Start hub container and run tests locally without nodes

D. Start selenium/node-firefox container first, then hub container

Solution

1. Step 1: Understand multi-browser setup

   To run tests on multiple browsers, you must start the hub and connect nodes for each browser to the hub's network.

2. Step 2: Evaluate options

   Start hub container, then start both selenium/node-chrome and selenium/node-firefox containers connected to the hub network correctly starts hub and both browser nodes connected properly. Start only selenium/node-chrome container; Firefox tests will run on Chrome node misses Firefox node, A misses nodes, and D starts nodes before hub which is incorrect.

3. Final Answer:

   Start hub container, then start both selenium/node-chrome and selenium/node-firefox containers connected to the hub network -> Option A

4. Quick Check:

   Hub + all browser nodes connected = multi-browser tests [OK]

Hint: Start hub first, then all browser nodes on same network [OK]

Common Mistakes:

• Starting nodes before hub
• Running tests without nodes
• Assuming one node can run all browsers