Unit 4: Selenium Validation and Grid - Subjective Questions

Maven is a build automation and dependency management tool commonly used for Selenium projects. It helps developers compile code, manage libraries, execute tests, and generate reports in a consistent manner.

Key points:

• The standard source directory is src/main/java, which contains application or framework code.
• The standard test directory is src/test/java, which contains test classes.
• Test resources such as configuration files are stored in src/test/resources.
• The target directory contains compiled classes, test reports, and generated build artifacts.
• The pom.xml file defines project metadata, dependencies, plugins, build goals, and execution settings.
• Maven downloads Selenium, TestNG, WebDriver, and other libraries from configured repositories.

This structure improves maintainability and allows the project to be built and tested using commands such as mvn test.

A Maven pom.xml file generally contains the following sections:

• Project coordinates: groupId, artifactId, and version uniquely identify the project.
• Properties: Used to define reusable values such as the Java version or dependency versions.
• Dependencies: Selenium WebDriver, TestNG, WebDriverManager, and reporting libraries are declared here.
• Scopes: A dependency can be assigned a scope such as test when it is needed only during test execution.
• Build plugins: Plugins such as the Maven Compiler Plugin and Maven Surefire Plugin compile code and execute tests.
• Repositories: Additional repositories may be specified when a dependency is not available in the default Maven Central repository.

Maven resolves transitive dependencies automatically. Therefore, the required supporting libraries are downloaded without manually adding every related JAR file.

TestNG is a Java testing framework inspired by JUnit and NUnit. It provides annotations, assertions, test grouping, parameterization, parallel execution, and reporting features.

Its important features include:

• Annotations such as @BeforeMethod, @Test, and @AfterMethod.
• Support for test groups and dependencies between test methods.
• Data-driven testing using @DataProvider.
• Configuration through testng.xml.
• Parallel execution of tests and suites.
• Built-in reports showing passed, failed, and skipped tests.
• Priorities and dependency management for controlling execution order.

TestNG is suitable for Selenium because browser tests often require setup and cleanup, multiple datasets, cross-browser execution, and organized reporting. These requirements are directly supported by TestNG APIs.

TestNG API documentation provides information about classes, methods, annotations, attributes, exceptions, and interfaces available in the framework.

A tester can use it effectively by:

• Locating the documentation for an annotation such as @Test or @BeforeClass.
• Checking the annotation attributes, including priority, groups, dependsOnMethods, dataProvider, and enabled.
• Reviewing method signatures and return types before using an API.
• Reading exception descriptions to identify invalid configurations or runtime errors.
• Checking version compatibility between the documentation and the TestNG dependency in pom.xml.
• Using examples and inherited interface information to understand framework behavior.

Consulting API documentation reduces incorrect assumptions and helps testers write reliable, version-compatible automation code.

The testng.xml file is used to organize and control TestNG execution. Its typical hierarchy is suite, test, and class.

Important configuration elements include:

• A <suite> element defines the complete execution collection.
• A <test> element represents a logical group of classes or methods.
• <classes> and <class> elements specify the Java test classes to execute.
• <methods> can include or exclude selected test methods.
• <groups> can include or exclude groups such as smoke or regression.
• <parameter> passes values such as browser name or environment URL.
• The parallel attribute can execute tests, classes, or methods concurrently.
• The thread-count attribute controls the maximum number of parallel threads.

This configuration separates execution decisions from Java code and supports repeatable suite execution.

Hard assertions stop the current test method immediately when an assertion fails. Examples include Assert.assertEquals, Assert.assertTrue, and Assert.assertFalse. They are useful when later steps depend on the condition being true.

Soft assertions record failures and allow the remaining statements to execute. In TestNG, SoftAssert is used, and assertAll() must be called at the end to report the collected failures.

Example uses:

• A hard assertion can verify that a login succeeded before attempting account operations.
• A soft assertion can validate several labels, links, or fields on a page in one test.

The main difference is execution flow: hard assertions fail immediately, whereas soft assertions delay failure reporting until assertAll() is invoked.

TestNG assertions compare actual application behavior with expected results. Common types include:

• Equality assertion: assertEquals(actual, expected) verifies that two values match.
• Inequality assertion: assertNotEquals(actual, unexpected) verifies that values differ.
• Boolean assertion: assertTrue(condition) verifies that a condition is true.
• Negative boolean assertion: assertFalse(condition) verifies that a condition is false.
• Null assertion: assertNull(value) verifies that a reference is null.
• Non-null assertion: assertNotNull(value) verifies that an object exists.
• Failure assertion: fail(message) deliberately fails a test when an unexpected path is reached.

In Selenium, assertions can validate page titles, URLs, element visibility, text, enabled state, selected state, and expected navigation results. A meaningful failure message should be added to make diagnosis easier.

TestNG annotations control test setup, execution, and cleanup. Common annotations are:

• @BeforeSuite: Runs once before the entire suite.
• @BeforeTest: Runs before the <test> section in testng.xml.
• @BeforeClass: Runs once before the first method in a class.
• @BeforeMethod: Runs before every @Test method.
• @Test: Marks a method as a test case.
• @AfterMethod: Runs after every test method.
• @AfterClass: Runs after all test methods in a class.
• @AfterTest: Runs after the configured <test> section.
• @AfterSuite: Runs once after the entire suite.

The usual lifecycle is @BeforeSuite, @BeforeTest, @BeforeClass, @BeforeMethod, @Test, @AfterMethod, @AfterClass, @AfterTest, and @AfterSuite. The exact behavior can be affected by multiple classes, inheritance, and configuration settings.

A maintainable test case can be created through the following process:

• Create a Maven project with standard source and test directories.
• Add Selenium WebDriver and TestNG dependencies to pom.xml.
• Define reusable setup code in @BeforeMethod or @BeforeClass.
• Initialize the required browser driver and navigate to the application URL.
• Use stable locators such as IDs, names, accessible attributes, or reliable CSS selectors.
• Perform one focused business action or workflow in the test method.
• Add assertions that verify observable outcomes rather than implementation details.
• Use explicit waits when synchronization is required.
• Close the browser in @AfterMethod or @AfterClass, even when the test fails.
• Add meaningful names, groups, and failure messages.

Separating setup, actions, assertions, and cleanup makes the test easier to understand and reuse.

A login test should validate the complete user-visible outcome rather than only checking that a click occurred.

Possible validations include:

• Before login: Verify that the login page has the expected title or heading.
• Input validation: Confirm that username and password fields are displayed and enabled.
• Action validation: Enter valid credentials and submit the form.
• Success validation: Assert that the resulting URL, dashboard heading, user name, or logout control is correct.
• Failure validation: For invalid credentials, assert that the expected error message is visible and that the user remains on the login page.
• Cleanup validation: Ensure the driver is closed after execution.

Assertions should use explicit expected values and descriptive messages. Explicit waits should be used before checking elements that appear after a server response.

Selenium Grid is a distributed execution system that allows Selenium tests to run on multiple browsers, operating systems, and machines. A test request is sent to a Grid endpoint, which routes it to a suitable browser session.

Selenium Grid is useful when:

• Tests must run on several browser types and versions.
• Different operating systems must be validated.
• Execution time needs to be reduced through parallel testing.
• Browser sessions must run on remote or cloud machines.
• A team needs centralized control of distributed test infrastructure.
• A project requires repeatable cross-browser compatibility testing.

Grid improves coverage and execution speed, but it also introduces infrastructure, networking, session-management, and diagnostic considerations.

Selenium Grid uses a distributed architecture in which test clients communicate with Grid services that identify and allocate suitable browser sessions.

The general request flow is:

• The test code creates browser capabilities, such as browser name, platform, and version.
• The WebDriver client sends a new-session request to the Grid endpoint.
• The Grid distributor or router examines available node capabilities.
• A compatible node is selected based on the requested capabilities.
• The node starts the requested browser session.
• Subsequent WebDriver commands are routed between the client and the selected node.
• The node returns command results, errors, and browser state to the client.
• When the test calls quit(), the session is closed and the node becomes available again.

This design separates test execution from the machine and browser that perform it.

The major Selenium Grid 4 components are:

• Router: Receives incoming WebDriver requests and directs them to the appropriate Grid component.
• Distributor: Matches requested capabilities with available nodes and assigns sessions.
• Session Map: Stores the relationship between a session ID and the node running that session.
• New Session Queue: Holds new-session requests until a compatible node is available.
• Event Bus: Enables communication between Grid components through events.
• Node: Provides the actual browser environments and executes WebDriver commands.
• Standalone mode: Combines the required components in a single process for simple local execution.
• Hub and Node mode: Separates central coordination from browser execution and is useful for distributed environments.

Together, these components provide routing, capability matching, session tracking, and remote browser execution.

Standalone mode:

• Runs all required Grid components in one process.
• Is simple to start and suitable for local development or small test runs.
• Has limited scalability because coordination and execution share one process.

Hub-node mode:

• Uses a central hub to coordinate one or more remote nodes.
• Makes distributed browser execution easier to manage.
• Can become dependent on the availability and capacity of the hub.

Fully distributed mode:

• Runs the Router, Distributor, Session Map, New Session Queue, Event Bus, and Nodes as separate processes.
• Provides greater scalability and flexible deployment.
• Requires more configuration, monitoring, and infrastructure management.

The appropriate mode depends on the required scale, fault tolerance, operational complexity, and number of browser environments.

Grid configuration defines how the server starts, how nodes connect, and which browser sessions are available.

Important configuration areas include:

• Port: The Grid endpoint listens on a port, commonly 4444, unless another port is specified.
• Node address: A node must be able to communicate with the Grid service over the network.
• Browser capabilities: The node advertises supported browser names, versions, platforms, and maximum session counts.
• Driver availability: The node requires the appropriate browser and driver, or an automated driver-management solution.
• Configuration files: TOML or command-line options can define ports, URLs, session limits, and browser settings.
• Session limits: Maximum sessions control resource usage and prevent machine overload.
• Health and registration: Nodes register with the Grid and provide status information.

Correct configuration ensures that requested capabilities can be matched to healthy and available nodes.

The main steps are:

• Start the Grid server and confirm that its endpoint is reachable.
• Create a MutableCapabilities or browser-specific options object.
• Set the required browser, platform, version, and other session capabilities.
• Create a RemoteWebDriver using the Grid URL and the capabilities.
• Navigate to the application under test.
• Locate elements and perform the required test actions.
• Implement assertions for the expected result.
• Use try and finally or a TestNG cleanup annotation to guarantee driver.quit().
• Record the browser and node information in logs for troubleshooting.

The test code should avoid assumptions about the local machine because the browser executes on the selected remote node.

During Grid execution:

• The test client sends a new-session request containing browser capabilities.
• The Grid examines the request and places it in the session queue if a suitable node is not immediately available.
• The distributor matches the request with a node that supports the required capabilities and has capacity.
• The selected node launches the browser and returns a session ID.
• Commands such as navigation, element interaction, and screenshots are routed to that node using the session ID.
• The node executes each command and sends the response back through the Grid to the client.
• If a test fails, logs, screenshots, and browser information assist diagnosis.
• The client sends a delete-session request through driver.quit().
• The Grid releases the node resources for another session.

Parallel execution can process multiple independent sessions simultaneously, provided that the infrastructure has sufficient capacity.

Cross-browser testing verifies that an application behaves correctly and presents a consistent user experience across different browsers, browser versions, and operating systems.

Selenium Grid and TestNG can be combined as follows:

• Define browser and platform values as TestNG parameters or data-provider values.
• Build browser-specific capabilities from those values.
• Create a RemoteWebDriver for each requested environment.
• Configure multiple browser combinations in testng.xml.
• Run independent tests in parallel using TestNG parallel settings.
• Use consistent assertions across browsers while allowing documented browser-specific behavior.
• Capture browser, version, platform, logs, and screenshots for each result.

The test matrix should prioritize supported and high-risk environments rather than attempting every possible combination without a coverage strategy.

An endpoint is a URL through which clients or administrators interact with the Grid. The exact paths can vary by Selenium Grid version and deployment mode, so the deployed version's documentation should be consulted.

Common endpoint purposes include:

• Root Grid endpoint: Used by WebDriver clients to create and manage remote sessions.
• Status endpoint: Reports whether the Grid is ready and provides information about components and nodes.
• Graphical console: Displays registered nodes, browser availability, and session activity.
• Node status endpoint: Helps inspect node health and available slots.
• Session-related routes: Route WebDriver commands for an existing session.
• Health or readiness routes: Used by deployment systems and monitoring tools to determine service availability.

Endpoints help distinguish client errors, capability mismatches, unavailable nodes, and Grid infrastructure failures.

A node can be customized by configuring the environment and the capabilities it advertises.

Typical customization steps are:

• Install the required browser and compatible WebDriver support on the node machine.
• Assign a meaningful node name or host address.
• Configure the browser name, browser version, and platform name.
• Set the maximum number of simultaneous sessions according to CPU and memory capacity.
• Add custom capabilities needed by the test framework.
• Configure the node port and connect it to the Grid endpoint.
• Restrict the node to selected browser types when isolation is required.
• Add logging, timeouts, and session-cleanup settings.
• Verify registration through the Grid status or console endpoint.

A node should advertise only capabilities it can actually provide. Incorrect advertisements cause session failures or tests to run in the wrong environment.