Selenium – java

Blog: Removal of AbstractEventListener + EventFiringWebDriver + WebDriverEventListener

Fri, 08 Dec 2023 00:00:00 +0000

Upgrading to WebDriverListener and EventFiringDecorator

Decorating the webdriver

new EventFiringWebDriver(driver); // Old approach
new EventFiringDecorator().decorate(driver); // New approach

Implementing method wrappers

One may find the need to have their own custom implementations be used for underlying decorated method calls. An example may be wanting to use your own findElement implementation to store metadata from web elements. One can go down a deep rabbit hole of decorators ( extending WebDriverDecorator and such ), so to keep things simple we will extend EventFiringDecorator since we want a single decorator to handle all our listener events.

public class WebDriverWrapper implements WebDriver {
 private final WebDriver driver;
 WebDriverWrapper(WebDriver driver) {
 this.driver = driver;
 }
 // custom implementation goes here
 @Override
 public WebElement findElement(final By by) {
 // custom implementation goes here
 return driver.findElement(by);
 }
}

public class testDecorator extends EventFiringDecorator<WebDriver> {

 @Override
 public Object call(Decorated<?> target, Method method, Object[] args) throws Throwable {
 String methodName = method.getName();
 if ("findElement".equals(methodName)) {
 WebDriverWrapper newDriver = new WebDriverWrapper((WebDriver) target.getOriginal());
 return newDriver.findElement((By) args[0]);
 }
 return super.call(target, method, args);
 }
}

Some notes about the above example, we are only overriding the ‘general’ call method and checking the method name against every call made. Without going too deep decorators one can also override calls made by class instances to offer a more targeted approach. Just to expose some more functionality, let’s modify our example. We can modify WebElement context since we might care about child elements and elements found by WebDriver ( WebDriver and WebElement both extend the SearchContext ).

public class WebElementWrapper implements WebElement {
 private final WebElement element;
 WebElementWrapper(WebElement element) {
 this.element = element;
 }
 @Override
 public WebElement findElement(final By by) {
 // custom implementation goes here
 return element.findElement(by);
 }
}

public class WebElementDecorator extends EventFiringDecorator<WebDriver> {
 @Override
 public Decorated<WebElement> createDecorated(WebElement original) {
 return new DefaultDecorated<>(original, this) {
 @Override
 public Object call(Method method, Object[] args) throws Throwable {
 String methodName = method.getName();
 if ("findElement".equals(methodName)) {
 // custom implementation goes here
 WebElementWrapper element = new WebElementWrapper(getOriginal());
 return element.findElement((By) args[0]);
 }
 return super.call(method, args);
 }
 };
 }
}

In the sample above, we are still doing a very similar approach of overriding the call method but now we are also targeting WebElement instances.

Registering Listeners

new EventFiringWebDriver(driver).register(listener1).register(listener2); // Old approach
new EventFiringDecorator(listener1, listener2); // New approach

Listening to Events

A quality of life change that is featured in WebDriverListener class is the use of ‘default’. In Java, the default keyword, when used in the context of an interface method, indicates that the method has a default implementation. If a class implementing the interface chooses not to override the method, it will inherit the default implementation. This change allows for splitting up listeners without needing to implement the unnecessary methods you don’t need or care about.

Listening to specific events using before/after methods call

// Old approach
public class AlertListener implements WebDriverEventListener {
 @Override
 public void beforeAlertAccept(final WebDriver driver) {
 // custom implementation goes here
 }
// implement every method in interface
}

// New approach
public class AlertListener implements WebDriverListener {
 @Override
 public void beforeAccept(Alert alert) {
 // custom implementation goes here
 }
// does not need to implement every method in interface
}

Listening to Generic Events

A change that was brought on is the ability to listen to generic events. One use case is logging information in a parallelized test suite. Rather than create a listener and override every method to add a simple log statement, there is now a simpler alternative of overriding one method call. Below I override beforeAnyCall, but afterAnyCall exists as well which also has the results of the call to the decorated method.

public class Listener implements WebDriverEventListener {
 private static final Logger LOGGER = Logger.getLogger(Listener.class.getName());

 @Override
 public void beforeAnyCall(Object target, Method method, Object[] args) {
 logger.debug("Thread: " + Thread.currentThread().getName() +
 " | Method Name: " + method.getName() +
 " | Method Args: " + Arrays.toString(args));
 }
}

There also was an addition listening to more specific generic events. Going back to the logging example, beforeAnyCall is a good method for debugging information or tracking the actions of a thread but might generate too much noise. In the same use case we might only care about WebDriver or WebElement calls. One can override instances of WebDriver and derived objects( WebElement, Alert, etc.) for before/after events.

public class Listener implements WebDriverEventListener {
 private static final Logger LOGGER = Logger.getLogger(Listener.class.getName());

 @Override
 public void beforeAnyWebDriverCall(WebDriver driver, Method method, Object[] args) {
 logger.debug("Thread: " + Thread.currentThread().getName() +
 " | Method Name: " + method.getName() +
 " | Method Args: " + Arrays.toString(args));
 }

 @Override
 public void beforeAnyWebElementCall(WebElement element, Method method, Object[] args) {
 logger.debug("Thread: " + Thread.currentThread().getName() +
 " | Method Name: " + method.getName() +
 " | Method Args: " + Arrays.toString(args));
 }
}

So that’s some general examples on how to transition your code! Happy testing!

Blog: Java 8 support in Selenium

Fri, 09 Jun 2023 00:00:00 +0000

“If it ain’t broke, don’t fix it” is a saying you may have heard, but sometimes it’s necessary to move on from our old favorites. That’s why we’re announcing that Selenium will stop supporting Java 8 on September 30, 2023. This applies for both the Java bindings and the Selenium Grid.

Selenium has long supported Java 8, but as technology evolves, so must we. One of the primary reasons for this change is that Java 8 reached the end of active support over a year ago. In addition, our default HTTP Client has not had a major release in several years, and a bug has been found that we can not fix. We have decided to move to the native Java HTTP Client, but it requires using Java 11 or greater. The sooner we make this change, the sooner we can avoid dealing with this issue.

Our new minimum version will be Java 11. September 30, 2023 is also the end of active support for Java 11. However, we want to take a cautious and conservative path forward, and not force our users to make the big jump from Java 8 to Java 17, as we understand the community might need longer to move to that version. We will revisit this topic in the future to announce the plan to support Java 17 as a minimum version.

We understand that this change may require some of our users to make adjustments, but we believe that it’s a necessary step for the continued growth of Selenium. Please take some time to check your infrastructure and ensure you’re running on Java 11 or higher. We understand that some may be hesitant or may find it difficult to make the switch, but we believe it will pay off in the long run.

Please let us know your questions, concerns, and feedback through our community chat.

Happy testing!

Blog: InvalidSelectorException has changed

Fri, 21 Apr 2023 00:00:00 +0000

Before Selenium 4.8.2 in Java and C#, when an invalid locator was used to identify an element, the resulting behavior would be inconsistent in our bindings.

For example, let’s check the following code:

ArrayList<Class<? extends Exception>> expectedExceptions = new ArrayList<>();
 expectedExceptions.add(org.openqa.selenium.NoSuchElementException.class);
 expectedExceptions.add(org.openqa.selenium.StaleElementReferenceException.class);
 expectedExceptions.add(org.openqa.selenium.ElementNotInteractableException.class);
 expectedExceptions.add(org.openqa.selenium.InvalidElementStateException.class);

return new FluentWait<>(driver)
 .withTimeout(Duration.ofMillis(ELEMENT_IDENTIFICATION_TIMEOUT))
 .pollingEvery(Duration.ofMillis(ELEMENT_IDENTIFICATION_POLLING_DELAY))
 .ignoreAll(expectedExceptions)
 .until(nestedDriver -> {
 nestedDriver.findElement(By.xpath("invalid-xpath")).click;
 });

The expected result before this change would be that the driver waits until the timeout expires and then throw an InvalidSelectorException.

This doesn’t make much sense because a broken/invalid selector would never fix itself, and hence should throw immediately.

This was discussed and agreed during the TLC meeting on August 17, 2022, and implemented through the pull request 11727 and the following commit.

With the changes mentioned above, an invalid selector will throw an InvalidSelectorException immediately.

Please note that this may have an impact on backwards compatibility if you are not expecting this exception to be thrown while handling invalid locators.

Stay tuned for updates by following SeleniumHQ!

Happy testing!

Blog: BELLATRIX Test Automation Framework for C# and JAVA

Wed, 16 Nov 2022 00:00:00 +0000

Over the last decade, a large ecosystem of Open Source projects has sprouted up around Selenium. Selenium is often used for automating web applications for testing purposes, but it does not include a testing framework. Nowadays, Selenium Ecosystem initiatives try to give popularity to popular open-source test automation frameworks maintained by people outside of the core Selenium maintainers. One of these frameworks is BELLATRIX, invented by Anton Angelov. It has two versions - C# and Java. A testing framework is an abstraction in which common code provides generic functionality (which can be selectively overridden) for testing different aspects of our applications- UI, API, security, performance, and many others.

BELLATRIX Test Automation Framework

The first version of BELLATRIX appeared on 26 December 2017. It was available only for C# initially, but written on the new back then .NET Core, allowing the framework to be used on all major operating systems (cross-platform). One huge advantage of BELLATRIX is its cross-technology readiness. It allows you to write tests for different technologies such as Web, Mobile, Desktop, and API. In BELLATRIX, we strive for the API for all modules to be as identical as possible.

The usage is simple. We suggest cloning BELLATRIX as a GIT sub-module. Then, any customizations, tests, and project-specific plug-ins should be placed in a project outside the BELLATRIX cloned repository. This way, you can quickly update to the latest version.

BELLATRIX official website, download and releases info

BELLATRIX official C# GitHub Page

BELLATRIX official Java GitHub Page

BELLATRIX C# Documentation

BELLATRIX Java Documentation

Let’s investigate how easy it is to create your first test with BELLATRIX in 15 minutes. The sample will showcase how to create a very basic test login into a website:

Open the BellatrixTestFramework.sln

Under the starthere folder, find the project you prefer: web, mobile, desktop, API

Open the BellatrixLoginTest.cs file. There you will find a sample test automating the login.

[TestClass]
public class LoginTestsMSTest : MSTest.WebTest
{
 public override void TestInit()
 {
 App.Navigation.Navigate("http://demos.bellatrix.solutions/my-account/");
 }

 [TestMethod]
 public void SuccessfullyLoginToMyAccount()
 {
 var userNameField = App.Components.CreateById<TextField>("username");
 var passwordField = App.Components.CreateById<Password>("password");
 var loginButton = App.Components.CreateByXpath<Button>("//button[@name='login']");

 userNameField.SetText("info@yourverybusywebsite.com");
 passwordField.SetPassword("yourverysecretp4ssw0rd$");
 loginButton.Click();

 var myAccountContentDiv = App.Components.CreateByClass<Div>("woocommerce-MyAccount-content");
 myAccountContentDiv.ValidateInnerTextContains("Hello John");

 var logoutLink = App.Components.CreateByInnerTextContaining<Anchor>("Log out");

 logoutLink.ValidateIsVisible();
 logoutLink.Click();
 }
}

All available services are available through the main App class. The Components property provides various Create methods for finding elements. They are generic, so you need to mention the type of the searched element. We have different elements because, for each of them, BELLATRIX offers various additional methods and assertions on top of native WebDriver methods. The sample code uses MSTest as the default test framework, but by changing the attributes, it will also work out of the box for NUnit. Of course, you need to change the base class namespace too.

Why BELLATRIX?

Let’s quickly list some of the essential things the framework brings to the table:

Multiple Test Environments Configuration

Every aspect of the framework can be controlled via a rich JSON configuration designed to work for many test environments. Web Project Configuration.

Customization

One of the hardest things to develop is to allow these generic frameworks to be extendable and customizable. Knowing how essential customization is, we utilize different ways to achieve it. The major one is about writing your own plug-ins.

Test Reliability

One of the biggest problems in test automation is handling timeouts and performing actions on elements that may not be on the page right now. BELLATRIX hides the complexity of searching and waiting for elements. Furthermore, when you perform an action or assertion against an element, we guarantee that once returned, it will be present.

A significant part of your tests are the assertions - checking whether some conditions are met. To handle such scenarios, we created elements Validate methods. They internally handle the whole complexity of waiting for some condition to happen.

updateCart.ValidateIsDisabled();
totalSpan.ValidateInnerTextIs("120.00€", timeout: 30, sleepInterval: 2);
messageAlert.ValidateIsNotVisible();

Complex Controls

BELLATRIX provides API that makes handling HTML tables and grids much easier HTML tables and grids.

Here is an example for asserting grid cells:

TestGrid.ForEachCell(cell => cell.AssertFontSize("14px"));
TestGrid.GetCell("Firstname", 1).ValidateInnerTextIs("Mary");
TestGrid.GetCell(0, 1).ValidateInnerTextIs("John");
TestGrid.GetCell<Employee>(cell => cell.PersonalEmail, 1).ValidateInnerTextIs("mary@hotmail.com");

There is much more complex stuff that you can do with both components so check the official documentation.

Integrations

Seamlessly integrate the framework with your existing tools and processes. Execute tests in the clouds, distribute and publish test results in reporting solutions. Maybe the most significant differentiators of the framework are its many integrations with popular tools such as Jira/qTest/Allure/ReportPortal and clouds such as AWS, Microsoft Azure, + many more. All these integrations leverage BELLATRIX plug-in architecture. For example, we have plug-ins for automatically generating/updating test cases based on our automated tests in qTest and AzureDevops or similarly creating automatic bug reports with steps to reproduce in Jira or Azure.

Dynamic Test Cases

Dynamic test cases are a unique feature in BELLATRIX, where the framework automatically generates test cases in a popular test case management system based on your automated tests. It will populate the title, description, and other necessary properties automatically. Moreover, it will generate human-readable steps and expected results. The most significant benefit is that it will keep up to date with your auto-generated test cases over time, no matter what you change in your tests. It is an excellent functionality which allows the non-technical people of your company to see what your tests are doing.

AI Validation of PDFs and Image

Azure Computer Vision is a service that can be used to extract printed and handwritten text from images and documents with mixed languages and writing styles. In contrast, Azure Form Recognizer is an AI-powered document extraction service that understands your document. You are not limited to PDFs only. You can use the same feature for extracting text from complex images. BELLATRIX comes with similar functionality based on the AWS cloud.

Email Testing

BELLATRIX offers a few utilities for email testing. There are a few scenarios where we need such integration. The first one is related to creating unique email inboxes and using them to submit various online forms. Later, we can read the emails via the services and check the content of the emails. It might be enough to verify the content via regular C#, or in some cases, we might need to interact with the email content in the browser.

There are tons of other integrations that we use on a daily basis in many big enterprise projects, such as cloud secrets management for securely storing credentials and other secrets. All BELLATRIX Integrations

Using BELLATRIX in your projects might save months/years of effort even if you have the required programming knowledge. This way, you can quickly focus on writing automated tests for your project. Usually, there are 4-6 major releases each year, including all bug fixes and new features. Check our release notes history. The framework is fully covered with over 4000 automated tests and offers rich documentation. We make sure to merge the new feature branches only when we are sure that everything is working. If some issue emerges after a major release, it is quickly fixed within a few days.

For feature requests or bug reports, you can submit them to our GitHub repositories. If you believe that the functionality you developed can be added to the CORE framework or you have a bug fix, please submit a PR so we can discuss it and potentially merge it. For anything else, you can reach us via our contact us form.

Blog: Removing Legacy Protocol Support

Fri, 20 May 2022 00:00:00 +0000

The Selenium team prides itself on how seriously it takes backwards compatibility. A lot of care has gone into the Java bindings, especially, to ensure very few breaking changes over the years. There is Selenium code written 15 years ago that can still run with Selenium 4 libraries! Providing this exceptional amount of support comes with a large maintenance burden, though, and we need to be able to properly meet the needs of the vast majority of our userbase.

TL/DR:

Support for the legacy JSON Wire Protocol will be removed from Java Selenium 4.9 (other languages have already removed this support)
Protocol conversions will stop in Selenium 4.9 Grid
You can ensure your sessions are W3C compliant by using Browser Options classes instead of the deprecated Desired Capabilities classes (and avoid using “set capability” methods directly)
If you rely on the current protocol conversion functionality, and it works for you, you can continue to use it with Selenium Grid 4.8

By far the biggest challenge in the past seven years of Selenium development has been transitioning the underlying implementation from the legacy JSON Wire Protocol to the new standardized W3C WebDriver Protocol. Because the WebDriver specification was being actively developed at the time, Selenium 3 supported both protocols simultaneously. We implemented “handshake” code to determine which protocol to use. When starting a session, Selenium would package the provided capabilities in both legacy and W3C formats, send them to the driver/server, and use whichever protocol was returned. This worked well for the most part. For many users, no changes were necessary to get W3C compliant sessions from new browsers (Firefox 47+ and Chrome 75+).

For the Java bindings, it was decided to take this approach one step further. Instead of just sending along what was provided in both formats, the code converted capabilities from the legacy protocol to the W3C protocol on behalf of the user. The Selenium Grid makes use of this code, so, regardless of which client language sends legacy capabilities to it, the Grid translates it to the W3C protocol for communication with the driver and then re-translates the results back to the legacy protocol. Because the code must make some assumptions and guesses for this to work, there are a lot of frustrating edge cases.

For Selenium 4.0, the Ruby, JavaScript, and .NET bindings, each removed the handshake code, so no legacy commands are used. Due to some issues that couldn’t be resolved before freezing the 3.x code, Python is waiting until Selenium 4.9 to remove its handshake code. The Selenium team intended to continue to support both protocols in the Grid and Java bindings throughout the 4.x releases, but running test suites written for Selenium 2 on the Selenium 4 Grid resulted in a larger than expected number of failures. Half a dozen bugs were discovered, some with a large effect.

The code in question is sufficiently complex that fixing the bugs without causing new problems would be a significant challenge. As such, we’ve decided to start simplifying the code base again by explicitly not supporting capabilities and commands from the legacy protocol in any of the Selenium codebase. If you are using the latest version of Java Selenium, everything that will be removed has already been marked deprecated, so double-check your usage to ensure there aren’t any surprises.

If you’re interested in the nitty-gritty details of some of the issues we found exploring this problem, you can look at the discussion in Selenium Issue #10374.

For more information on ensuring compatibility with the Grid, please follow our Selenium 4 Upgrade Guide