Session 53: Selenium with Java | Hybrid Framework | Run Tests on Selenium Grid

Technological concepts covered: Selenium Grid + Java execution on remote browsers/OS

Goal of Selenium Grid

• Execute automated Selenium WebDriver tests on remote machines.
• Simulate different operating systems and browsers so results match real customer/client environments.

Why run on multiple platforms/browsers?

• Users may run different combinations of OS + browser.
• Running tests across combinations helps ensure the tests pass reliably for all supported environments.

Core Grid architecture

Selenium Grid is built around two main components:

• Hub: the “control/main” system where tests are started and distributed.
• Node: remote machines where browsers are installed and where tests actually run.

How Grid routes tests

• When a test specifies:
  • platform (OS) and
  • browser
• The Hub selects an appropriate Node that matches those requirements.

---

Grid setup types explained

1. Standalone setup

   • One single machine acts as both Hub and Node.
   • Useful for practice (no extra VMs/containers required).

2. Distributed setup

   • One Hub machine + multiple Node machines.
   • Requirements:
     • Nodes must be on the same network.
     • Each Node must have access to the Selenium Grid server jar.

3. Docker concept (preview / next class)

   • Docker Hub typically provides images, not ready-to-use nodes directly.
   • Workflow:
     • download image → create container → use the container as a Node
   • Docker is positioned as a simpler, modern alternative to managing multiple VMs.

---

Practical tutorial content: starting Grid without Docker (Standalone / Java)

Prerequisite

• Download the Selenium Grid server jar from the Selenium website.

Start Grid in Standalone mode (Hub + Node on same machine)

• Run a Java command using the jar with the standalone parameter.
• The server prints a Grid Console/Dashboard URL (default port: 4444).

Verify Grid works

1. Open the Grid console URL in a browser.
2. Check:
   • available sessions
   • configured browser/OS capacities (e.g., counts like 16 Chrome / 16 Firefox)
3. Observe session lifecycle:
   • sessions appear while tests run
   • sessions disappear/close after execution

---

How to run tests on Grid from the automation framework (code-level changes)

New pieces introduced in the framework

1. Use Hub URL + RemoteWebDriver

• Replace local WebDriver instantiation with RemoteWebDriver for remote execution.
• RemoteWebDriver requires:
  • Hub URL (as a URL object)
  • DesiredCapabilities specifying:
    • platform (OS)
    • browserName

2. DesiredCapabilities configuration

• Platform and browser are set based on:
  • OS + browser values coming from the test definitions (XML)
  • mapping logic in code (e.g., if OS is Windows → set Platform.Windows)

Minimal strategy to keep code reusable

• The framework aims to run with the same base code for:
  • local execution
  • remote execution via Grid
  • (later) different Grid setups such as standalone/distributed/docker
• This is done by adding a configuration switch.

---

Configuration tutorial: choose local vs remote execution

config.properties addition

• Add:
  • execution_environment = local
  • OR execution_environment = remote

Behavior

• Local:
  • use normal local driver creation (e.g., ChromeDriver, FirefoxDriver, EdgeDriver).
• Remote:
  • build DesiredCapabilities
  • create RemoteWebDriver pointing to the Hub URL

---

Base class logic changes (remote vs local)

Base class setup method logic

• If execution_environment is remote:

  • Build DesiredCapabilities
  • Determine:
    • platform from the OS passed via XML
    • browserName from the browser passed via XML
  • Create:
    • RemoteWebDriver(new URL(HubURL + "/wd/hub"), capabilities)

• If local:

  • use the original local WebDriver code path.

Logging/error visibility note

• Grid errors/logging are primarily visible on the Hub side.
• Browser actions occur on Nodes, so those details are handled there.

---

Demonstration/verification workflow included

Run-and-check process

• Run tests with:
  • local mode enabled → Grid console shows no active sessions
  • switch to remote mode → Grid console shows active sessions while tests execute

Parallel testing on Grid

• Uses parallel XML setup to run the same/different tests across multiple browsers simultaneously.
• Grid behavior:
  • creates multiple sessions up to available capacity
  • excess requests may queue until sessions free up

Session lifecycle behavior

• Sessions appear during execution.
• Sessions close automatically after test completion.

Stopping Grid

• Closing the Grid console window stops the environment.
• Start Grid again by re-running the jar command.

---

Key “how-to” summary list (tutorial outputs)

• Download the Selenium Grid server jar.
• Start Standalone Grid:
  • run jar with standalone
  • copy the printed Grid URL (port 4444)
• Update automation framework:
  • add execution_environment in config.properties
  • in Base class:
    • if remote → configure DesiredCapabilities from XML (OS + browser)
    • if remote → use RemoteWebDriver(HubURL, capabilities)
    • if local → use normal local WebDriver instantiation
• Confirm via Grid console:
  • sessions show active OS/browser allocations during remote runs
• Use parallel XML files to validate Grid parallel execution.

---

Main speakers / sources

• Primary speaker: the tutorial instructor delivering “Session 53: Selenium with Java | Hybrid Framework | Run Tests on Selenium Grid”
• Source referenced: official Selenium website (for downloading the Selenium Grid server jar)