Selenium 3 vs Selenium 4

 

Selenium has four components as below:

 

 

Earlier Selenium interacted with browsers. The request and response of communication are through JSON Wire protocol. The JSON Wire protocol encodes and decodes all the communications between Selenium and the Browsers.

 

 

 

Selenium 4.0
- initially announced in 2018. we had got alpha and beta versions.
- officially released the first stable version of Selenium 4 On October 13, 2021, and brought lots of upgrades with this release

 

What’s New in Selenium 4

-          Selenium is now W3C compliant

-          Relative locators: Elements can be located based on the location of the neighbouring elements.

-          Better Window/Tab management

-          Improved Selenium Grid

-          Upgraded Selenium IDE

-          New APIs for CDP (Chrome DevTools Protocol)

-          Deprecation of Desired Capabilities. New Options class introduced.

-          Modifications in the Actions class

Selenium is now W3C compliant

W3C: The World Wide Web Consortium

-          JSON wire protocol was used to communicate between the Selenium WebDriver APIs and the browser native APIs.

-          With W3C compliance, communication happens directly without required encoding and decoding.

-          Any software following W3C standard protocol can be integrated with Selenium with no compatibility issues.

Relative locators:

-          Functions to locate nearby elements in specific directions.

-          Existing locator strategy

o   id

o   name

o   linkText

o   partialLinkText

o   className

o   tagName

o   XPath

o   cssSelector

-          New relative locators

o   above

o   below

o   toLeftOf

o   toRightOf

o   near

Better Window/Tab management:

-          work with multiple windows or tabs in the same session.

-          Can now open multiple windows/tabs without creating a new driver object.

o   Open a new window and switch to the window

§  Driver.switchTo().newWindow(WindowType.WINDOW);

o   Open a new tab and switch to the tab

§  Driver.switchTo().newWindow(WindowType.TAB);

Improved Selenium Grid:

-          Selenium Grid helps in Distributed Test Execution.

-          Enables test execution on different combinations of browsers, OS, and machines

-          Enables parallel execution.

Selenium Grid is now redesigned

-          Docker support

-          Enables to spin up the containers. (No need to set up VMs)

-          Enables to deploy the grid on Kubernetes for better scaling

-          Easier management – No need to set up and start hubs and nodes separately.

3 ways to run Selenium Grid

Standalone mode	The new Selenium Server Jar contains all the functionalities needed to run a grid  java -jar selenium-server-4.0.0.jar standalone  The Grid automatically identifies that the WebDrivers for Chrome and Firefox are present on the system.
Hub and Node	The classical way of using the Grid for Selenium test automation consists of two major components – Hub and Nodes.  Start hub java -jar selenium-server-4.0.0.jar hub Register node java -jar selenium-server-4.0.0.jar node –detect-drivers
Distributed	Grid 4 can be started in a fully distributed manner, with each piece running in its process.  Selenium Grid 4 consists of FOUR processes: Router Distributor Session Node

 

 Upgraded Selenium IDE:

-          Record and Playback tool

-          Available as an add-on – Firefox, Chrome, MS Edge

o   Improved GUI

o   SIDE runner – Selenium IDE runner for CMD execution, grid and node projects

o   Better element locator strategy

o   More stable and reliable

New APIs for CDP (Chrome DevTools Protocol):

Chrome DevTools – set of tools built directly into Chromium-based browsers like Chrome, Opera and Microsoft Edge to help developers debug and investigate websites

-          Inspect elements in the DOM

-          Edit elements and CSS on the fly

-          Check and monitor the site’s performance

-          Mock faster/slower networks speeds

-          Mock geolocations of the user

-          Execute and debug JavaScript

-          View console logs

Selenium 4 comes with native support for Chrome DevTools APIs

-          Capture and monitor network traffic

-          Simulate poor network conditions

-          Perform geolocation testing

-          Change device mode to do responsive design testing

-          new ChromiumDriver class, which includes two methods to access Chrome DevTools:

o   getDevTools()

o   executeCdpCommand()

Deprecation of Desired Capabilities:

Desired Capabilities were primarily used in the test scripts to define the test environment (browser name, version, operating system) for execution on the Selenium Grid.

 Capabilities objects are replaced with the Options class.

Firefox – FirefoxOptions

Chrome – ChromeOptions

Internet Explorer – InternetExplorerOptions

Microsoft Edge – EdgeOptions

Safari – SafariOptions

 

For example:

 ChromeOptions options = new ChromeOptions();

options.setAcceptInSecureCerts(true);

options.setCapability(“build”, “Testing Chrome Options Selenium 4”);

options.setCapability(“name”, “Testing Chrome Options Selenium 4”);

options.setCapability(“platformName”, “Windows 10”);

options.setCapability(“browserName”, “chrome”);

options.setCapability(“browserVersion”, “latest”);

 

Modifications in the Actions class:

Actions class is used to simulate input actions from mouse and keyboard on specific web elements (e.g., Left click, Right-click, Double click, etc.)

	Old	New
Click on a web element	moveToElement(element).click()	click(element)
Click on element without releasing the click	moveToElement(element).clickAndHold()	clickAndHold(element)
Right click	moveToElement(element).contextClick()	contextClick(element)

 release() initially a part of org.openqa.selenium.interactions.ButtonReleaseAction class. Is now part of Actions class.

 

 

Cucumber report

Please refer to this link

https://stackoverflow.com/questions/51257224/maven-cucumber-reporting-plugin-is-not-generating-the-report-nothing-happens

Difference between get() vs navigate() in Selenium

Selenium offers two distinct functions, get() and Maps(), for loading web pages. While both serve the fundamental purpose of directing the browser to a URL, they possess unique advantages and disadvantages that make them suitable for different scenarios. This article will delve into a detailed comparison of these two functions.

What is the get() function in Selenium?

The get() function in Selenium WebDriver is used to open a specified URL in the browser. Its primary purpose is to initiate a new browser session and navigate directly to the given web address. This method is straightforward and efficient for simply loading a web page from a URL.

What is the Maps() function in Selenium?

In Selenium WebDriver, the Maps() method is part of the WebDriver.Navigation interface. It offers more advanced capabilities for managing browser history and navigation compared to the get() method. The Maps() method allows users to move forward and backward through the browser's history, refresh the current page, and also navigate to a specific URL. Its purpose is to provide more granular control over browser navigation, extending beyond just loading a URL.

Difference Between get() and Maps() in Selenium

The following table highlights the key differences between the get() and Maps() functions in Selenium:

Factors	get()	Maps()
Interface Part	Part of the WebDriver interface.	Part of the Navigation interface.
Wait for Webpage Load	Waits until the webpage is fully loaded and available before returning control.	Does not inherently wait for the webpage to be fully loaded.
History Tracking	Does not have a history tracking feature, thus preventing users from going back to previous pages via the browser's history.	Has a history tracking feature, allowing users to go back to previous web pages.
Refresh Feature	Does not support the refresh feature.	Supports the refresh feature, allowing the current page to be reloaded.
Forward Feature	Does not support the forward function to move to the next page in browser history once the user has moved back.	Supports the forward function, allowing the user to move to the next page in browser history after navigating back.

POM

 

Understanding POM

The Page Object Model (POM) is a design pattern in test automation that separates UI elements, actions, and test scenarios into different files or classes. This helps make tests easier to read, reuse, and maintain, especially for web applications. It can be implemented using Page Factory (with @FindBy annotations for lazy loading) or without it (using driver.findElement() for more control).

Is POM a Waste of Time and Money?

It seems likely that POM is not inherently a waste, but its value depends on how it's used. Critics, like Eldad Uzman, argue it can add unnecessary overhead for simple cases or require skilled teams, potentially increasing costs. However, many experts highlight its benefits for long-term maintenance, suggesting it's worth the investment for complex projects. The evidence leans toward POM being effective when aligned with project needs, but it may not suit every scenario, especially if creating a single framework for all applications, as POM is typically application-specific.

Other Design Patterns

There are several alternatives to POM, such as:

• Screenplay Pattern: Focuses on natural language tests, often used with BDD tools like Serenity.
• Facade Pattern: Simplifies complex interactions by providing a unified interface.
• Singleton Pattern: Ensures one instance of a class, useful for managing resources like WebDriver.
• Factory Pattern: Creates objects without specifying exact classes, helpful for test data.
• Data-Driven Testing: Separates test data from logic, allowing varied data sets.
• Keyword-Driven Testing: Uses keywords for readable, maintainable tests.
• Behavior-Driven Development (BDD): Focuses on user behavior, often with Cucumber.

Each pattern has strengths, and choosing depends on project complexity and team expertise.

Overview of Page Object Model (POM)

POM is a design pattern widely adopted in test automation, particularly for web applications using tools like Selenium. It structures code by separating locators (UI elements), actions (methods), and tests (scenarios) into distinct files or classes, typically organized in a folder structure like:

• pages/: Contains page classes with locators and actions.
• tests/: Holds test scripts, often using frameworks like TestNG or JUnit.
• utilities/: Includes reusable utilities like Excel readers or driver setups.
• resources/: Stores test data, property files, or WebDriver executables.

POM can be implemented in two ways:

• Using Page Factory: Utilizes @FindBy annotations for element location, offering lazy initialization and concise, readable code.
• Without Page Factory: Relies on driver.findElement() within methods, providing more control, often preferred for dynamic scenarios.

The benefits of POM include:

• Code Reusability: Methods can be reused across different test scripts, reducing duplication.
• Code Maintenance: Changes to locators only require updates in page classes, not tests.
• Improved Readability: Separates test logic from UI structure, making scripts cleaner.

The phrase "Write test script once, reuse everywhere" encapsulates POM's advantage, aligning with goals of easy maintenance and scalability.

Addressing the Criticism: Is POM a Waste of Time and Money?

The user's claim that POM is a "waste of time and money" and a "fraudulent way of milking time and money" suggests a strong skepticism, possibly rooted in perceived inefficiencies or misapplication. To evaluate this, we consider both supportive and critical perspectives.

Supportive View: Many sources, such as Why Use Page Object Model in Test Automation? - TestingXperts, emphasize POM's role in facilitating agile environments by ensuring test cases remain aligned with evolving product features. It reduces code redundancy and improves reliability, making it a standard practice for maintainable test suites. The Advantages of Using the Page Object Model (POM) Framework in Test Automation - SJ Innovation LLC highlights its efficiency for web application testing, lowering error rates and enhancing quality.

Critical View: Critics, notably Eldad Uzman in A case against Page Object Model — part2 - Medium, argue POM can be overrated. He points out:

• Many page objects are stateless, making their creation overhead for simple cases.
• It may lead to conditional test logic and flakiness if internal state is held.
• Dynamically typed languages (e.g., Python) with static type checkers can mitigate some issues, but constraining coders might lead to workarounds.
• Additional patterns like PageFactory or Screenplay are seen as red flags, not solving fundamental POM problems.

Disadvantages of Page Object Model in Selenium - Stack Overflow notes POM requires skilled labor and is application-specific, not generic, unlike data-driven or keyword-driven frameworks. This specificity aligns with the user's concern about creating a framework for all applications, as POM is typically per application, potentially increasing costs if applied universally without adaptation.

Given these perspectives, POM is not inherently fraudulent but may be inefficient if misapplied, especially for simple projects or teams lacking expertise. The evidence leans toward POM being valuable for complex, maintainable test suites, but its cost-benefit must be assessed per project.

Alternatives to POM: Other Design Patterns

The user's query also seeks other design patterns for test automation frameworks. Several alternatives exist, each with unique strengths:

• Screenplay Pattern: Gaining popularity, especially with Serenity BDD, it focuses on natural language tests using actors and abilities. Test Automation Design Patterns: Boosting Efficiency and Code Quality - Medium notes its relevance for readable, maintainable tests.
• Facade Pattern: Simplifies complex interactions by providing a unified interface, useful for combining multiple page objects. Test Automation Design Patterns For Mobile Testing - Kobiton provides examples, like login/logout workflows, reducing dependency on individual page objects.
• Singleton Pattern: Ensures one instance of a class, ideal for managing resources like WebDriver. Design Patterns for Scalable Test Automation Frameworks - DZone highlights its utility in global resource management.
• Factory Pattern: Creates objects without specifying exact classes, useful for generating page objects or test data dynamically. 8 Test Automation Design Patterns for Clean Code - MuukTest discusses its role in extensibility.
• Data-Driven Testing: Separates test data from logic, allowing tests to run with varied datasets, enhancing reusability. TOP 5 Test Automation Framework Design Patterns - LinkedIn lists it as a key pattern for scalability.
• Keyword-Driven Testing: Uses keywords to define test cases, improving readability and maintainability, often used in hybrid frameworks. Page Objects in Test Automation - Advantages and Disadvantages of Keyword Driven tests - Ultimate QA discusses its benefits over record-replay approaches.
• Behavior-Driven Development (BDD): Focuses on user behavior, often implemented with Cucumber, enhancing collaboration between technical and non-technical stakeholders. Design Patterns in Automation Framework - BrowserStack mentions its alignment with agile practices.

These patterns offer flexibility, and the choice depends on factors like application complexity, team expertise, and project timelines, as noted in Test Automation Design Patterns - HeadSpin.

Comparative Analysis: POM vs. Alternatives

To illustrate, here's a table comparing POM with key alternatives based on common criteria:

Pattern	Maintainability	Reusability	Complexity	Best For
Page Object Model (POM)	High	High	Medium-High	Complex web apps, skilled teams
Screenplay Pattern	High	High	Medium	Readable tests, BDD frameworks
Facade Pattern	Medium-High	Medium	Low-Medium	Simplifying complex workflows
Singleton Pattern	Medium	Low	Low	Resource management, global state
Factory Pattern	Medium-High	High	Medium	Dynamic object creation
Data-Driven Testing	High	High	Medium	Varied test data, scalability
Keyword-Driven Testing	High	High	Low-Medium	Readable, less technical teams
BDD	High	Medium-High	Medium	User behavior, stakeholder input

This table underscores that while POM excels in maintainability for complex UIs, alternatives like Screenplay or Data-Driven Testing may suit different needs, such as readability or scalability.

Conclusion

POM is a robust design pattern for test automation, offering significant benefits for maintainability and reusability, but it's not universally optimal. The user's concern about it being a waste of time and money is valid in contexts where it's misapplied, such as for simple applications or without skilled teams. However, for complex projects, it remains a valuable tool. Alternatives like Screenplay, Facade, Singleton, Factory, Data-Driven Testing, Keyword-Driven Testing, and BDD provide viable options, and the choice should align with project requirements and team capabilities.

TestNG Listeners

 TestNG provides a bunch of listeners as a part of its testing environment. These listeners are as follows:

1. ITestListener
2. IRetryListener
3. IReporter
4. ISuiteListener
5. IInvokedMethod
6. IHookable
7. IConfigurationListener
8. IConfigurableListener
9. IAnnotationTransformer
10. IExecution
11. IMethodInterceptor

Retry Failed Tests in TestNG

TestNG provides various listeners to customize our needs. One such powerful listener is IRetryListener using which you can retry a test case multiple times before declaring it as Failed.

If you see a failure can just automatically rerun the test to make sure that the test is consistently failing. this way it reduces false failures because of random issues and you spend more time debugging true failures.

IRetryListener interface has only one method public boolean retry(ITestResult result);

This method will be called whenever a test method fails. You can get the details of the test from ITestResult input argument to this method. This method implementation should return true if you want to re-execute your failed test and false if you don't want to re-execute your test.

Page load using JavascriptExecutor

public static boolean waitForPageLoad(WebDriver driver, int timeout){

ExpectedCondition<Boolean> pageLoadCondition = new ExpectedCondition<Boolean>(){
public Boolean apply(WebDriver driver){
return ((JavascriptExecutor)driver).executeScript("return document.readyState");
}
};

WebDriverWait wait = new WebDriverWait(driver, timeout);
return wait.until(pageLoadCondition); 

}