Unit 4: Selenium Validation and Grid

I. Orientation

Selenium validation combines browser automation with build management, test orchestration, assertions, and distributed execution. Maven supplies reproducible project builds, TestNG structures and validates test cases, and Selenium Grid runs WebDriver sessions across multiple browsers, operating systems, and machines.

• Governing principle: A test performs an action, observes the application state, and uses an assertion to compare the actual result with the expected result.
• Automation layers:
  • Maven: Manages dependencies, compilation, test execution, and reports.
  • TestNG: Defines test lifecycle, grouping, parameterization, and assertions.
  • Selenium WebDriver: Controls a browser through the W3C WebDriver protocol.
  • Selenium Grid: Routes WebDriver sessions to suitable remote browser nodes.
• Basic test flow: Arrange preconditions, act through WebDriver, assert the outcome, and clean up browser resources.
• Reproducibility convention: Versions and configuration belong in files such as pom.xml and testng.xml, rather than depending on manually configured machines.
• Reliability requirement: Tests should use stable locators, explicit waits, independent data, meaningful assertions, and guaranteed teardown.

II. Maven-Based Selenium Projects — Build and Dependency Management

A. Introduction to Maven project

A Maven project organizes source code and automates the build through a standard lifecycle and a Project Object Model.

• Project Object Model: pom.xml identifies the project and declares dependencies, plugins, properties, and build behavior.
• Coordinates: Maven identifies an artifact using groupId, artifactId, and version, such as com.example:ui-tests:1.0.0.
• Standard layout:
  • src/main/java: Application or reusable production code.
  • src/test/java: Selenium and TestNG test classes.
  • src/test/resources: TestNG suites, test data, and test resources.
  • target: Compiled classes, reports, and other generated output.
• Lifecycle: mvn test passes through phases including validation, compilation, test compilation, and test execution.
• Dependency resolution: Maven downloads declared libraries and transitive dependencies from configured repositories into the local repository.

B. Maven Project configuration

Maven configuration makes Selenium and TestNG versions explicit and connects TestNG to Maven's test phase.

• Dependencies: selenium-java provides WebDriver APIs, while testng provides annotations, runners, and assertions.
• Compiler property: maven.compiler.release selects a Java language and bytecode level supported by the installed JDK.
• Surefire plugin: maven-surefire-plugin discovers and runs tests during mvn test; it can also select a testng.xml suite.
• Illustrative configuration:

<properties>
  <maven.compiler.release>17</maven.compiler.release>
</properties>

<dependencies>
  <dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>4.27.0</version>
  </dependency>
  <dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>7.10.2</version>
    <scope>test</scope>
  </dependency>
</dependencies>

• Version control: Teams should pin compatible versions and commit pom.xml; available versions can be updated deliberately rather than implicitly.
• Execution: mvn clean test removes previous output and executes the test lifecycle from a clean state.

III. TestNG — Test Structure, Lifecycle, and Validation

A. Introduction to TestNG

TestNG is a Java testing framework that organizes automated tests through annotations, suites, groups, dependencies, parameters, and reporting.

• Test method: A public method marked @Test becomes executable without requiring a main method.
• Organization: XML suites can contain multiple <test> elements, classes, packages, methods, or groups.
• Data-driven testing: @DataProvider supplies multiple argument sets to one test method.
• Parallelism: Suites may run methods, classes, tests, or instances concurrently when test isolation permits it.
• Reporting: TestNG records passed, failed, and skipped methods and generates reports under the configured output directory.

B. TestNG API Documentation

TestNG API documentation defines the contracts of annotations, assertion classes, listeners, result objects, and suite interfaces.

• Core packages:
  • org.testng: Includes Assert, ITestResult, ITestContext, and listener interfaces.
  • org.testng.annotations: Includes @Test, configuration annotations, @DataProvider, and @Parameters.
  • org.testng.asserts: Includes soft-assertion support.
• Annotation attributes: Documentation specifies options such as groups, dependsOnMethods, priority, enabled, dataProvider, and invocationCount.
• Result inspection: ITestResult exposes method status, parameters, timing, and thrown exceptions to listeners and reporters.
• Practical use: API signatures should be checked against the project's exact TestNG version because available methods and behavior can evolve.

C. TestNG configuration

TestNG configuration controls which tests run, how they receive values, and whether execution is sequential or parallel.

• Suite file: testng.xml is the conventional declarative configuration file.
• Selection: <classes>, <methods>, and <groups> include or exclude test units.
• Parameters: <parameter> values can be injected into methods annotated with @Parameters.
• Parallel execution: parallel="tests" and thread-count="2" allow two <test> blocks to execute concurrently.
• Example:

<suite name="CrossBrowserSuite" parallel="tests" thread-count="2">
  <test name="Chrome">
    <parameter name="browser" value="chrome"/>
    <classes><class name="tests.LoginTest"/></classes>
  </test>
  <test name="Firefox">
    <parameter name="browser" value="firefox"/>
    <classes><class name="tests.LoginTest"/></classes>
  </test>
</suite>

• Build integration: Surefire can reference the suite through its suiteXmlFiles configuration.

D. Types of assertions and annotations

Assertions determine pass or failure, while annotations define when and under what conditions test code executes.

1. Assertion types:
   • Hard assertions: Assert.assertEquals(actual, expected) throws AssertionError immediately when the comparison fails.
   • Soft assertions: SoftAssert records multiple failures; assertAll() must be called to report them.
   • Common checks: assertTrue, assertFalse, assertNull, assertNotNull, assertSame, and fail express distinct expectations.
2. Annotation types:
   • Suite lifecycle: @BeforeSuite and @AfterSuite.
   • Test-block lifecycle: @BeforeTest and @AfterTest, where “test” means a <test> element in testng.xml.
   • Class lifecycle: @BeforeClass and @AfterClass.
   • Method lifecycle: @BeforeMethod and @AfterMethod run around each @Test method.
   • Supporting annotations: @DataProvider, @Parameters, @Factory, and @Listeners provide data, object creation, and extension hooks.

IV. Test Development — Cases and Assertions

A. Test Case Creation

A Selenium test case translates one verifiable requirement into controlled browser actions and observable outcomes.

• Precondition: Define the starting URL, browser state, user account, and required test data.
• Arrange: Create the driver, configure timeouts, and navigate to the application.
• Act: Locate elements using stable attributes such as id, name, or dedicated test identifiers, then perform user actions.
• Synchronize: Use WebDriverWait for conditions such as visibility or clickability; avoid fixed sleeps that depend on timing guesses.
• Expected result: State a measurable outcome, such as the heading text equalling "Dashboard".
• Cleanup: Place driver.quit() in @AfterMethod(alwaysRun = true) so browser processes close even after failure.
• Independence: Each case should establish its own state and avoid relying on another test's execution order.

B. Implementing assertions

Assertion implementation should validate business-visible outcomes and provide enough context to diagnose failures.

• Value capture: Read the actual value after waiting for the relevant browser state.
• Correct comparison: Use equality for exact text, Boolean assertions for conditions, and collection assertions for ordered results.
• Message quality: Add a failure message describing the expectation, not merely “test failed.”
• Example:

String actual = new WebDriverWait(driver, Duration.ofSeconds(10))
    .until(ExpectedConditions.visibilityOfElementLocated(By.tagName("h1")))
    .getText();

Assert.assertEquals(actual, "Dashboard",
    "Successful login should display the dashboard heading");

• Soft assertion rule: Multiple related checks may use SoftAssert, but the method must end with softAssert.assertAll().
• Scope: Assert the intended result rather than incidental implementation details such as generated CSS classes.

V. Selenium Grid — Distributed and Cross-Browser Execution

A. Selenium Grid

Selenium Grid executes WebDriver tests remotely by assigning session requests to registered browser-capable machines.

• Remote driver: Tests use RemoteWebDriver with a Grid URL and browser options.
• Main benefit: Independent tests can run concurrently, reducing total suite duration.
• Environment coverage: Nodes may expose different browsers, versions, operating systems, and device-related capabilities.
• Constraint: Grid increases infrastructure capacity but does not repair flaky locators, shared test data, or unsafe parallel code.

B. Grid Architecture

Selenium Grid 4 uses cooperating services to receive requests, match capabilities, create sessions, and track session ownership.

• Standalone mode: All Grid services run in one process, suitable for local use or small suites.
• Hub-and-node mode: A hub hosts central services while separate nodes provide browser slots.
• Distributed mode: Services run as separate processes for scalability and operational control.
• Request path: Client request → Router → New Session Queue → Distributor → Node; active-session routing uses the Session Map.
• Matching rule: Requested capabilities, such as browserName=firefox, must match an available node slot.

C. Grid Components

Each Grid component performs a specific coordination or execution responsibility.

• Router: Receives external WebDriver commands and sends them to the appropriate internal service.
• Distributor: Tracks node capacity, selects a compatible slot, and initiates new sessions.
• Node: Owns browser slots and executes commands against local browser instances.
• Session Map: Records the relationship between a session ID and the node running it.
• New Session Queue: Holds session requests until matching capacity becomes available or the request times out.
• Event Bus: Carries internal events that allow distributed components to coordinate.
• Slot: Represents the capacity to run one browser session with a defined stereotype.

D. Grid Configuration

Grid configuration defines server roles, addresses, capacity, timeouts, and browser stereotypes.

• Server acquisition: The Selenium Server JAR requires a compatible Java runtime and is launched with java -jar selenium-server-<version>.jar.
• Standalone command:

java -jar selenium-server-4.27.0.jar standalone

• Hub and node commands:

java -jar selenium-server-4.27.0.jar hub
java -jar selenium-server-4.27.0.jar node --hub http://localhost:4444

• Configuration files: TOML files support repeatable settings through --config, including node limits and driver definitions.
• Network requirement: Nodes must reach the hub, and test clients must reach the Router, normally exposed on port 4444.
• Security: An externally reachable Grid requires network controls and authentication measures because WebDriver permits powerful remote browser operations.

E. Create Test Script

A Grid test script requests capabilities and sends normal WebDriver commands through a remote endpoint.

• Browser options: ChromeOptions, FirefoxOptions, or another browser-specific options class describes the requested session.
• Remote connection:

WebDriver driver = new RemoteWebDriver(
    URI.create("http://localhost:4444").toURL(),
    new ChromeOptions()
);
try {
    driver.get("https://example.com");
    Assert.assertEquals(driver.getTitle(), "Example Domain");
} finally {
    driver.quit();
}

• Capability matching: Additional capabilities should describe genuine requirements, such as platform or browser version, because excessive constraints reduce available matches.
• Portability: The test body remains largely identical to a local WebDriver test; driver construction changes.

F. Test Execution

Grid execution combines the Maven/TestNG runner with remote session allocation and browser-side command processing.

• Preparation: Start Grid, confirm node registration, and ensure the requested browsers and drivers are available.
• Invocation: Run mvn test; TestNG discovers methods and each method creates its own remote session.
• Parallel safety: A WebDriver instance must not be shared across concurrent test threads; use method-local drivers or thread-isolated storage.
• Observation: The Grid UI and status endpoint reveal nodes, slots, and active sessions.
• Failure handling: Preserve TestNG reports, browser logs, screenshots, and Grid logs while still calling quit().

G. Cross Browser Testing

Cross browser testing runs the same behavior checks against multiple browser engines to detect compatibility differences.

• Browser matrix: A practical matrix may include current Chrome, Firefox, and Edge, plus required operating systems.
• Parameterization: The browser value from testng.xml selects the relevant options object before creating RemoteWebDriver.
• Parallel execution: Separate <test> entries can run browsers simultaneously when Grid has enough slots.
• Comparison target: Validate user-visible behavior, layout-critical states, JavaScript interactions, downloads, alerts, and navigation.
• Maintenance: Prioritize browsers supported by product requirements; an unnecessarily large matrix raises runtime and infrastructure cost.

H. Endpoints

Grid endpoints expose WebDriver operations, health information, and Grid-specific observability interfaces.

• WebDriver endpoint: Clients send POST /session to create a session and use session-scoped routes for commands.
• Status endpoint: GET /status reports whether the Grid is ready to accept sessions and provides Grid state details.
• Grid UI: Opening the Grid server address in a browser displays registered nodes and slot availability.
• GraphQL endpoint: /graphql supports structured queries about Grid state for monitoring and tooling.
• Base URL: Selenium Grid 4 commonly uses http://host:4444; the older /wd/hub path is generally unnecessary for modern clients.
• Operational rule: Publicly exposing administrative or WebDriver endpoints creates a serious security risk.

I. Customizing a Node

Node customization controls capacity, advertised browser capabilities, session behavior, and operational features.

• Concurrency: max-sessions limits simultaneous sessions; increasing it beyond available CPU and memory can reduce reliability.
• Stereotypes: A node can advertise slot templates containing capabilities such as browser name, browser version, and platform.
• Automatic discovery: Driver detection can create slots from browsers and drivers installed on the node.
• Managed drivers: Selenium Manager support can be enabled where automatic driver management is appropriate and network policy allows it.
• Node configuration example:

[node]
max-sessions = 4
override-max-sessions = false
detect-drivers = true
session-timeout = 300

• Operational customization: Nodes may be configured for video, downloads, managed browser images, or containerized execution when the deployment supplies those facilities.
• Capacity principle: Node limits should reflect measured processor, memory, and browser consumption rather than the theoretical maximum number of slots.