Unit 1: Introduction to Selenium - Subjective Questions

Selenium was originally developed by Jason Huggins in 2004 while he was working at ThoughtWorks.

• Huggins created a JavaScript-based tool to automate the testing of an internal web application.
• The tool was initially called JavaScriptTestRunner.
• It was later renamed Selenium, partly as a reference to selenium being an antidote to mercury, while Mercury Interactive was a major testing-tool vendor at the time.
• Paul Hammant joined the project and developed the server-based approach that became Selenium Remote Control (RC).
• Simon Stewart started the WebDriver project to overcome the limitations of Selenium RC.
• Selenium WebDriver and Selenium RC were subsequently merged under the Selenium 2 project.
• Selenium is now an open-source project maintained by a global community of developers and contributors.

Selenium is an open-source suite of tools used to automate interactions with web browsers and test web applications.

Major features:

• Supports browsers such as Chrome, Firefox, Edge, and Safari.
• Supports programming languages including Java, Python, C#, JavaScript, Ruby, and Kotlin.
• Can perform user actions such as clicking, typing, selecting options, navigating, and submitting forms.
• Supports execution on local computers, remote computers, and distributed environments.
• Integrates with testing frameworks such as JUnit, TestNG, NUnit, and pytest.
• Can be integrated into continuous integration pipelines.

Applications:

• Functional testing
• Regression testing
• Cross-browser testing
• Data-driven testing
• End-to-end testing
• Repetitive browser-task automation

Selenium is primarily intended for web applications. It does not directly automate desktop applications.

The major Selenium components are:

• Selenium IDE: A browser extension that records and plays back browser actions. It is useful for learning, prototyping, and creating simple automated tests.
• Selenium WebDriver: A programming interface that controls browsers through browser-specific drivers. It is the main component used to build maintainable automation frameworks.
• Selenium Grid: A tool for running tests on multiple browsers, operating systems, and machines in parallel or remotely.

Historical component:

• Selenium RC: A legacy component that used a server to inject JavaScript into the browser. It was replaced by WebDriver because WebDriver provides more direct, reliable, and efficient browser control.

Together, these components support test creation, browser automation, and distributed execution.

Summary:

• Selenium IDE is appropriate for quick test creation.
• WebDriver is used for robust and maintainable automation.
• Grid extends WebDriver execution across multiple machines and browser environments.
• In a complete automation solution, WebDriver tests can be distributed through Selenium Grid.

A Java-based Selenium environment can be installed as follows:

1. Install a Java Development Kit: Install a supported JDK and verify it using java -version and javac -version.
2. Configure Java: Set JAVA_HOME if required and ensure the Java executable is available through the system path.
3. Install an IDE: Download and install Eclipse IDE or another Java IDE.
4. Create a Java project: A Maven or Gradle project is preferable because dependencies can be managed automatically.
5. Add Selenium: For Maven, add the selenium-java dependency to pom.xml. For Gradle, add it to the dependencies section of build.gradle.
6. Add a test framework: Add JUnit or TestNG to organize and execute tests.
7. Install browsers: Ensure that browsers such as Chrome and Firefox are installed.
8. Configure drivers: Modern Selenium versions include Selenium Manager, which can discover, download, and configure compatible drivers automatically. Drivers can also be configured manually when necessary.
9. Verify installation: Create a simple test that starts a browser, opens a web page, checks its title, and closes the browser.

A successful browser launch confirms that the environment is configured correctly.

The Eclipse IDE can be configured for Selenium testing through the following steps:

1. Visit the official Eclipse website and download the current Eclipse Installer for the operating system.
2. Run the installer and select Eclipse IDE for Java Developers.
3. Choose an installation directory and complete the installation.
4. Start Eclipse and select a workspace directory.
5. Open Window > Preferences > Java > Installed JREs and verify that a suitable JDK is configured.
6. Create a project using File > New > Maven Project or create a standard Java project.
7. Add Selenium and a test framework such as JUnit or TestNG as project dependencies.
8. If using TestNG, install the TestNG Eclipse plug-in when required by the project setup.
9. Allow Eclipse or Maven to download the dependencies and then update the project if necessary.
10. Create source and test packages with meaningful names.
11. Run a sample test using Run As > JUnit Test, TestNG Test, or Java Application, depending on its structure.

The Eclipse console should display the execution result, while the configured WebDriver should launch and control the selected browser.

Using Maven:

• Create or convert the Eclipse project into a Maven project.
• Add the Selenium Java dependency to pom.xml.
• Save the file so Maven downloads Selenium and its transitive dependencies.
• Update the project through Maven > Update Project if Eclipse does not refresh automatically.

Example dependency structure:

<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>current-version</version>
</dependency>

Using JAR files manually:

• Download the Selenium Java package from the official Selenium website.
• Extract the downloaded archive.
• Open the project properties in Eclipse.
• Select Java Build Path > Libraries > Add External JARs.
• Add the required Selenium JAR files and their dependency JARs.

Comparison:

Maven is generally preferable because it manages versions and transitive dependencies automatically. Manual JAR configuration requires developers to download, add, and update every required library themselves.

A basic Java Selenium script can be written as follows:

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;

public class FirstSeleniumScript {
public static void main(String[] args) {
WebDriver driver = new ChromeDriver();
try {
driver.get("https://example.com");
System.out.println(driver.getTitle());
} finally {
driver.quit();
}
}
}

Explanation:

• WebDriver defines the standard browser-control interface.
• ChromeDriver creates a session in Google Chrome.
• driver.get(...) navigates to the specified URL.
• driver.getTitle() obtains the title of the current page.
• try and finally ensure that cleanup occurs even if navigation or another operation fails.
• driver.quit() closes every window in the session and releases the driver process.

With modern Selenium, Selenium Manager can usually manage the required browser driver automatically.

A well-organized Selenium test generally contains four phases:

1. Setup:

   • Create the WebDriver instance.
   • Configure browser options, timeouts, and window size.
   • Prepare test data or navigate to an initial page.

2. Execution:

   • Locate the required web elements.
   • Perform actions such as entering text, clicking buttons, or selecting values.

3. Verification:

   • Retrieve the actual application state.
   • Compare it with the expected result using assertions.
   • Examples include checking a title, URL, message, or element state.

4. Teardown:

   • Capture diagnostic information if a test fails, when supported by the framework.
   • Call driver.quit() to close the complete browser session.

Testing frameworks such as JUnit or TestNG provide annotations for these phases. This structure reduces duplication, improves cleanup reliability, and makes tests easier to maintain.

To create and run a Selenium test in Eclipse:

• Create a Maven project and add Selenium plus either JUnit or TestNG dependencies.
• Create a test class under the test source directory.
• Define setup, test, and cleanup methods using the framework's annotations.
• Initialize WebDriver in a setup method.
• Place browser actions and assertions in a test method.
• Close WebDriver in a cleanup method.

Typical annotation flow:

• JUnit may use @BeforeEach, @Test, and @AfterEach.
• TestNG may use @BeforeMethod, @Test, and @AfterMethod.

To run the test, right-click the class and select Run As > JUnit Test or Run As > TestNG Test. Eclipse then displays passed, failed, and skipped results in the corresponding test view. A failed assertion marks the test as failed, while teardown should still close the browser session.

WebDriver replaced Selenium RC because its architecture provides more direct, reliable, and maintainable automation. Selenium RC may still be discussed for historical understanding, but it should not be selected for a new automation project.

Selenium WebDriver was introduced to provide more direct and dependable browser automation than Selenium RC.

Limitations of Selenium RC:

• It required a separate Selenium RC server to run.
• Commands passed through additional communication and JavaScript layers, increasing complexity and execution time.
• Browser actions were simulated mainly through injected JavaScript.
• JavaScript security restrictions could affect automation behavior.
• It had difficulty reproducing some native browser interactions accurately.
• Its API was less convenient for building modern, maintainable test frameworks.

Improvements provided by WebDriver:

• Browser control through browser-specific automation interfaces and drivers
• Better support for native events and browser behavior
• A cleaner and more object-oriented API
• Improved execution performance and reliability
• Active support for current browsers and standards

These improvements made WebDriver the central browser-automation API in modern Selenium.

AUT means Application Under Test. In web automation, it is the website or web application whose behavior is being verified.

To launch an AUT:

1. Create the appropriate WebDriver instance, such as ChromeDriver or FirefoxDriver.
2. Configure browser options if necessary.
3. Use driver.get("URL") to open the application's address.
4. Wait for the required page or element state.
5. Verify that the correct application has loaded by checking the title, URL, heading, or another stable element.
6. Perform test actions and assertions.
7. End the session with driver.quit().

Example:

WebDriver driver = new ChromeDriver();
driver.get("https://example.com");

The AUT must be reachable from the test machine. For local or test environments, the application server should be started before test execution.

The same AUT can be launched in different browsers by creating different WebDriver implementations.

Chrome:

WebDriver driver = new ChromeDriver();
driver.get("https://example.com");

Firefox:

WebDriver driver = new FirefoxDriver();
driver.get("https://example.com");

Role of browser drivers:

• Chrome uses ChromeDriver.
• Firefox uses GeckoDriver.
• The driver translates WebDriver commands into operations supported by the target browser.
• The browser and driver must be compatible.
• Selenium Manager can usually discover or obtain a compatible driver automatically in current Selenium versions.
• In controlled environments, driver binaries may instead be managed manually or through an organization-specific driver manager.

Because both classes implement the WebDriver interface, the main test logic can often remain browser-independent.

A browser-independent test separates browser creation from test logic.

Approach:

1. Read the browser name from a test parameter, configuration file, environment variable, or build command.
2. Use a factory method to create the correct driver.
3. Store the resulting object in a variable of type WebDriver.
4. Execute the same navigation, interaction, and assertion code.
5. Close the session in teardown.

Example factory logic:

if (browser.equalsIgnoreCase("chrome")) {
driver = new ChromeDriver();
} else if (browser.equalsIgnoreCase("firefox")) {
driver = new FirefoxDriver();
} else {
throw new IllegalArgumentException("Unsupported browser");
}

Benefits:

• Avoids duplicating test cases for each browser.
• Makes cross-browser execution easier.
• Centralizes browser-specific configuration.
• Supports extension to remote execution through Selenium Grid.

Assertions should remain identical unless the application intentionally behaves differently across browsers.

Web elements are objects represented in the page's Document Object Model, such as text fields, buttons, links, checkboxes, images, and lists.

To inspect an element:

1. Launch the AUT in Chrome or Firefox.
2. Open developer tools using the browser menu, a keyboard shortcut, or Inspect from the element's context menu.
3. Use the element-selection tool and select the required item on the page.
4. Examine its HTML tag, attributes, text, parent elements, and child elements.
5. Identify stable properties that can be used as locators.
6. Test CSS selectors in the developer-tools search facility or XPath expressions in the appropriate console or inspector facility.

Useful properties include:

• id
• name
• class
• type
• href
• data-* attributes
• Visible text
• Relationships with nearby elements

Stable, unique attributes are preferable to dynamically generated values or fragile location-based paths.

Selenium WebDriver provides several locator strategies through the By class:

• ID: By.id("username") locates an element by its id attribute.
• Name: By.name("email") locates an element by its name attribute.
• Class name: By.className("submit-button") uses one class value.
• Tag name: By.tagName("input") locates elements by HTML tag.
• Link text: By.linkText("Sign in") finds a link by its complete visible text.
• Partial link text: By.partialLinkText("Sign") finds a link using part of its visible text.
• CSS selector: By.cssSelector("form#login button[type='submit']") uses CSS syntax.
• XPath: By.xpath("//button[@type='submit']") uses an XPath expression.

A good locator should be unique, stable, readable, and independent of visual position. A stable id or dedicated test attribute is usually preferable. CSS selectors and XPath are useful when simple attributes are insufficient.

Absolute XPath:

• Begins at the root of the document, for example /html/body/div/form/input.
• Depends heavily on the complete DOM structure.
• Breaks easily when containers are added or moved.
• Is generally unsuitable for maintainable automation.

Relative XPath:

• Locates an element from any suitable point, for example //input[@name='email'].
• Can navigate through parent, child, sibling, and text relationships.
• Is useful when an element must be identified through surrounding structure or text.

CSS selector:

• Uses CSS syntax, for example input[name='email'].
• Is often concise and readable for attribute and hierarchy-based selection.
• Does not directly provide all XPath capabilities, such as general parent-axis navigation or standard text matching.

Stable CSS selectors and relative XPath expressions are both appropriate. The choice should be based on clarity, uniqueness, and resistance to expected DOM changes.

After inspecting an element, Selenium can locate and interact with it through a WebElement.

Example:

WebElement username = driver.findElement(By.id("username"));
username.clear();
username.sendKeys("student@example.com");

A button can be clicked as follows:

driver.findElement(By.cssSelector("button[type='submit']")).click();

Process:

• Select a stable locator using the inspected HTML properties.
• Pass the locator to findElement.
• Wait until the required condition is true when the element loads asynchronously.
• Perform an operation such as click(), sendKeys(), clear(), or getText().
• Verify the resulting application state with an assertion.

findElement returns the first matching element and throws an exception if no match is found. findElements returns a list and returns an empty list when no elements match.

A complete login-test workflow includes the following stages:

1. Prepare the environment:

   • Install the JDK, Eclipse, Selenium, a test framework, and supported browsers.
   • Confirm that the AUT is available.

2. Inspect the AUT:

   • Open the login page in a browser.
   • Inspect the username field, password field, submit button, and result element.
   • Select stable locators such as IDs or dedicated test attributes.

3. Set up WebDriver:

   • Create ChromeDriver or FirefoxDriver.
   • Configure the browser window and timeouts.

4. Launch and exercise the AUT:

   • Navigate using driver.get(...).
   • Wait for the username field to become visible.
   • Enter valid credentials and click the login button.

5. Verify the result:

   • Wait for a post-login element or URL condition.
   • Assert that the expected dashboard, user name, URL, or success message is displayed.

6. Handle cleanup:

   • Use framework teardown or a finally block to call driver.quit().

A reliable implementation avoids fixed delays where possible, keeps credentials outside source code, uses explicit waits for dynamic states, and records useful failure details such as screenshots or browser logs.