Selenium – webdriver

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: 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: Dev and Beta Channel Browsers via Docker Selenium

Tue, 23 Aug 2022 00:00:00 +0000

The Docker Selenium browser Beta and Dev channel releases are now regularly published to Docker Hub and updated every two days. This enables testers and developers to test their applications on pre-release versions of Google Chrome, Mozilla Firefox, and Microsoft Edge before their official releases, using container tools, such as Docker. This empowers teams to stay ahead of the curve and catch potential showstoppers in their CI environment before those issues have an impact on their users.

What are “release channels”?

Here’s some background on release channels: Google, Mozilla, and Microsoft all maintain different “channels” for their respective browser releases. Most end users use the “Stable” channel. The Stable channel releases have passed rigorous testing, and these versions are considered “production-ready”. Up until now, this was the only option for a tester or developer when using Docker Selenium. Today, we’re pleased to announce teams can also test on versions of these browsers yet to be released to the general population. These are the Beta and Dev channels.

For clarity, here is Google’s description of these 3 channels from their “Chrome Release Channels” page:

Stable channel: This channel has gotten the full testing and blessing of the Chrome test team, and is the best bet to avoid crashes and other issues. It’s updated roughly every two-three weeks for minor releases, and every 6 weeks for major releases.

Beta channel: If you are interested in seeing what’s next, with minimal risk, Beta channel is the place to be. It’s updated every week roughly, with major updates coming every six weeks, more than a month before the Stable channel will get them.

Dev channel: If you want to see what’s happening quickly, then you want the Dev channel. The Dev channel gets updated once or twice weekly, and it shows what we’re working on right now. There’s no lag between major versions, whatever code we’ve got, you will get. While this build does get tested, it is still subject to bugs, as we want people to see what’s new as soon as possible.

Standalone Usage:

To use these new Docker Selenium container images in Standalone mode, run the following commands:

Chrome Beta:

$ docker run --rm -it -p 4444:4444 -p 7900:7900 --shm-size 2g selenium/standalone-chrome:beta

Chrome Dev:

$ docker run --rm -it -p 4444:4444 -p 7900:7900 --shm-size 2g selenium/standalone-chrome:dev

Firefox Beta:

$ docker run --rm -it -p 4444:4444 -p 7900:7900 --shm-size 2g selenium/standalone-firefox:beta

Firefox Dev:

$ docker run --rm -it -p 4444:4444 -p 7900:7900 --shm-size 2g selenium/standalone-firefox:dev

Edge Beta:

$ docker run --rm -it -p 4444:4444 -p 7900:7900 --shm-size 2g selenium/standalone-edge:beta

Edge Dev:

$ docker run --rm -it -p 4444:4444 -p 7900:7900 --shm-size 2g selenium/standalone-edge:dev

Selenium Grid

To run these container images in a Selenium Grid, we’ll use docker-compose. For instance, this example shows how to run a Selenium Grid with Chrome, Firefox, and Edge on the Beta channel:

docker-compose-v3-beta-channel.yml:

# To execute this docker-compose yml file use `docker-compose -f docker-compose-v3-beta-channel.yml up`
# Add the `-d` flag at the end for detached execution
# To stop the execution, hit Ctrl+C, and then `docker-compose -f docker-compose-v3-beta-channel.yml down`
version: "3"
services:
 chrome:
 image: selenium/node-chrome:beta
 shm_size: 2gb
 depends_on:
 - selenium-hub
 environment:
 - SE_EVENT_BUS_HOST=selenium-hub
 - SE_EVENT_BUS_PUBLISH_PORT=4442
 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

 edge:
 image: selenium/node-edge:beta
 shm_size: 2gb
 depends_on:
 - selenium-hub
 environment:
 - SE_EVENT_BUS_HOST=selenium-hub
 - SE_EVENT_BUS_PUBLISH_PORT=4442
 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

 firefox:
 image: selenium/node-firefox:beta
 shm_size: 2gb
 depends_on:
 - selenium-hub
 environment:
 - SE_EVENT_BUS_HOST=selenium-hub
 - SE_EVENT_BUS_PUBLISH_PORT=4442
 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

 selenium-hub:
 image: selenium/hub:latest
 container_name: selenium-hub
 ports:
 - "4442:4442"
 - "4443:4443"
 - "4444:4444"

To run on the more cutting edge – and hence potentially more buggy – Dev channel, simply replace the “beta” tags with “dev”.

Support

These Beta and Dev images represent pre-release browsers and WebDrivers, and they’re not guaranteed to be 100% stable. Should you run into any issues with these images, support from the Selenium community is limited and is dependent on the browser vendors. However, if you believe the issue is related to Selenium, please contact us in the various support channels.

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

Blog: Locate your locators - Python bindings changes upcoming

Tue, 01 Feb 2022 00:00:00 +0000

In real estate, the mantra for finding a new house or office space is “location, location, location!”. It could be said that when working with Selenium, a critical aspect of writing tests is “locators, locators, locators!”. Having a robust locator strategy - in your app under test and in your test framework - is highly important for effective testing.

If you are a Pythonista like myself and using Selenium for your test automation, then there are some important changes coming to how locators are defined and used.

Sometime after Selenium 4.2, the Python Selenium bindings will remove locator-specific methods for finding elements. This means that the methods

driver.find_element_by_id("some_id")
driver.find_element_by_name("some_name")
driver.find_element_by_tag_name("some_tag")
driver.find_element_by_css_selector("some_selector")
driver.find_element_by_class_name("some_class")
driver.find_element_by_link_text("some_text")
driver.find_element_by_partial_link_text("some_other_text")
driver.find_element_by_xpath("some_xpath")

will be removed. All of these methods are in fact special cases of

driver.find_element(By_object, "some_locator")

so this approach is now preferred (required, even) with the Python bindings.

Note that it’s good practice to use the By object which has specific values for using particular locator strategies. For example, this line

driver.find_element_by_id("submit_button").click()
driver.find_element_by_css_selectors('.myelement child').text

becomes

driver.find_element(By.ID, "submit_button").click()
driver.find_element(By.CSS_SELECTOR, '.myelement child').text

If you’re really desperate however you can use strings instead of the By object:

driver.find_element('id', "submit_button").click()
driver.find_element('css selector', '.myelement child').text

If you have any plans to upgrade your Selenium client for your Python tests to recent versions of Selenium 4, definitely keep these changes in mind. It’s a good time to update your locator strategy and structure.

(This article was originally posted here. Thanks to the Selenium core contributors for adding this here!)

Blog: IE Mode in Edge supported by IEDriver

Tue, 18 Jan 2022 00:00:00 +0000

With the retirement of Internet Explorer 11 (IE 11) later this year, the folks in Redmond have helped the Selenium project with getting IE Mode in Microsoft Edge working in IEDriver.

IE 11 is due to retire on 15 June 2022 for certain versions of Windows 10. After this date, the Selenium project recommends that you test your IE sites with IE Mode in Microsoft Edge. The Selenium Project will not remove support for IE 11 when it retires but we will not actively fix issues as we have done with previous versions of IE.

The Microsoft Edge team have committed to supporting IE Mode in Edge until 2029 when support for Windows 10 is retired.

Microsoft have written up all the details on how to use and how to migrate your site and we recommend you go read and follow their steps to make sure you’re ready.

Blog: A Tour of 4: New Commands

Wed, 13 Oct 2021 00:00:00 +0000

Before we ship Selenium 4, I thought it would be nice to introduce some of the new features in-depth. Of course, all of the features we’re covering are in the main WebDriver documentation, so if you’re not one for reading blog posts, then feel free to dive in there!

You may well be familiar with how to start a Selenium server: you just do something like java -jar selenium-server-4.0.0.jar standalone and away you go! But with Selenium 4, there are some more things you can do with this jar.

Least obviously, the server jar is an exectuable on its own. If you’re using Linux or macOS, and have Java installed, you can make the jar executable (eg. chmod 755 selenium-server-4.0.0.jar), rename it to something like selenium and put it on your $PATH. That way, rather than writing java -jar ... you can simply run selenium.

Now you’ve done that, if you run selenium with selenium --help you’ll get a handy list of the available sub-commands you can execute. There are the old favourites, such as standalone (for starting a standalone selenium server), and hub and node (for starting a Selenium Hub and Node setup), but there are other interesting commands that are new to Selenium 4.

The first of these is info. We’ve added this to provide easy to find and access documentation on common tasks when using the selenium server. If you run selenium info on its own, you’ll see something like this:

Info
====

You can find out more about topics concerning Selenium Grid by running the
"info" command followed by:

* config - Help on how to configure Selenium
* tracing - Help on how distributed tracing works with selenium
* security - Help on how how to secure communications to and within selenium
* sessionmap - Help on different types of sessionmap and how to start them.


Each topic will give you enough information to help you get started, and contains
some pointers on our site to provide more complete information.

To get more information on a particular topic, just add the name of the topic, for example selenium info security. The hope is that this will make it less daunting to deal with Selenium, and give you a great place to get started with some of the more complicated topics around running a Selenium Grid.

Although it’s incredibly flexible, the selenium command offers a daunting list of command line flags. How are you supposed to remember them all? You’re not! Instead, let selenium completion take the strain for you. If you’re a zsh user, then just source <(selenium completion zsh), and now you have tab completion for the sub-commands, as well as for all the flags, including examples of how to use them.

And, finally, there are some hidden flags. We hid them because they can be a little bit confusing to use or understand what they’re meant to do, but one that can be very useful when debugging how your Grid is configured is the --dump-config flag. When run with a server command such as standalone or hub, it will dump the configuration options used by the Grid as a JSON blob. This can be helpful for tracking down subtle issues with configurations, especially when using environment properties for configuration.

Blog: A Tour of 4: Authentication

Sun, 10 Oct 2021 00:00:00 +0000

The first thing I’d like to introduce you to is Selenium 4’s new-found ability to authenticate to websites. We’ve always been able to handle “form-based” authentication, where a login page has some INPUT elements that you need to enter the user name and password, but handling sites that use basic or digest authentication has always been harder. When using Selenium 3, the advice has been to get the login cookie and set it on your session before accessing the site, but you can now just call a register method to add a user name and password (or, in the future, other kinds of authentication credentials)

In short, in Selenium 4, the process has become less complicated. Perhaps an example will help?

// This "HasAuthentication" interface is the key!
HasAuthentication authentication (HasAuthentication) driver;

// You can either register something for all sites
authentication.register(() -> new UsernameAndPassword("admin", "admin"));

// Or use something different for specific sites
authentication.register(
 uri -> uri.getHost().contains("mysite.com"),
 new UsernameAndPassword("AzureDiamond", "hunter2"));

driver.register(username: 'admin', password: 'admin')

Once you’ve done this, every time the driver loads a page that needs authentication, it will automatically use the user name and password you’ve given it.

This feature is currently implemented on top of Selenium 4’s CDP support, and so only works on those browser that support that protocol, but as we push forwards with development of WebDriver Bidi implementations will switch to that when they can.

Blog: Results of the first ever selenium survey

Tue, 12 Jan 2021 00:00:00 +0000

Below is a summary of the Selenium survey that was collected.

Batteries included

Browser Management

Unsurprisingly, people find having to manage browsers a task they wish they didn’t have to do and wish that Selenium did this. 59.5% of respondents want Selenium to manage the browsers for them. This, though the question didn’t ask this, is to include the browser drivers.

Frameworks

The results show an interesting view into framework usage. 61% of users use a framework. When we look closer at some of the responses there could be a little language bias in there. Some responses in the “both” category are “depends on the language” or “depends on the project”. Frameworks, from a couple responses seem to be around JavaScript mostly.

How tests are run

One of the questions that was the most surprising was that people dislike running their tests in headless. 57% of people don’t want headless. This is surprising since puppeteer and playwright are up and coming tools that default to headless.

Browsers

People tend to favour evergreen, or the latest version from auto updating browsers, with over 55% of people wanting that. When we look at the data closer then people tend to do evergreen and then a specific version for IE.

People are also, overwhelmingly I should add, wanting to test on multiple browsers. 78% of people test with multiple browsers. This goes against the Chrome only support that we see on social media. The most used browsers for testing are (Percentage of respondents testing with browser):

Google Chrome (98%)
Firefox (67%)
Microsoft Edge (33%)
Safari (29%)
IE (13.5%)

One thing that is clear is that Testing against multiple browsers is hard. 51.6% say it’s hard and a further 27.3% being 3 out of 5. This is likely where some frameworks are becoming popular as it removes some of the need to understand the asynchronicity of browsers. This still has its problems in puppeteer and playwright as they add similar wait libraries to what Selenium has.

Mobile Browsers

One of the most surprising things to have come out of survey was the want to use mobile browsers more.

Of the 410 respondents 367 want to test on mobile. Interestingly, this goes well past just Chrome for Android and Safari for iOS.

Below is a list of browsers and percentage of users wanting to use it. Questions were designed for Android unless it said iOS. See note at the end of the section.

Firefox for Android: 38%
Chrome: 91%*
Microsoft Edge: 14%
Samsung Internet: 16.6%
Safari on iOS: 69%

*Note that the questionaire only mentioned Chrome so it could be a conflation between platforms here. 1 Person used the other field to add Chrome for iOS.

Language support

Language support is what one would suspect with most users using Java or python.

java: 67%
python: 31%
ruby: 6.1%
.NET: 17.6%
JavaScript: 21.4%
PHP: 1.5%

Improvements

After reviewing the “What one thing would you improve about Selenium I was able to narrow most of the responses down to similar types.

Below is a breakdown of the issues that people would like to see improved.

Happiness

Of the 410 respondents, 219 had something nice to say about Selenium and were thankful for the product being around.

Some of the main reasons are simplicity of APIs, good backwards compatibility, and it being open source

Blog: Browser Testing and Tools WG Meeting @ TPAC 2020

Thu, 29 Oct 2020 00:00:00 +0000

It’s that time of the year where working groups from the W3C meet up to discuss the various standards that are being worked on.

Within the Browser Testing and Tools Working Group, there are 2 different standards.

We have:

The first is what is commonly supported by the Selenium Project and has support from Apple, Mozilla, Microsoft, and Google in their browsers. It is also supported by various Selenium in the cloud providers like Sauce Labs and BrowserStack.

As the world has moved on we have felt the need to add new APIs and move Selenium to be more event-driven. This is where we are learning, and collaborating, with projects like Puppeteer to make sure that we can improve the Browser Automation space. This is where the WebDriver-Bidi Specification comes in. It has broad support from the browser vendors so you can use official browsers and not be limited by the JavaScript sandbox. Some of the newer frameworks can’t guarantee that.

If you’re curious about we discussed this week, feel free to read it up on the W3 Wiki.

This post was originally shared on David Burns’ Blog

Blog: Atoms have come to Selenium IDE

Thu, 09 Dec 2010 00:00:00 +0000

As mentioned in Simon’s Going Atomic: Why? and Going Atomic: How, part of the merging of Selenium and WebDriver is to share common code between the two. And as of the 1.0.10 release of Selenium IDE, this merged code, ‘atoms’ is now included.

Some early users of this release are noticing that this the atom that drives assertAttribute and verifyAttribute is causing their scripts to break. This post explains the ‘why’ and suggests how to fix them as well.

The HTML spec has the notion of a boolean attribute which is one that does something just by being there rather than by its value; checked and selected are two such examples of this. Optionally, you could give these boolean attributes a value that is the same as their name (checked=”checked”) and your page would still validate, but really, the browsers only care that the attribute exist.

Prior to 1.0.10, it was not uncommon for people to do something like

 assertAttribute | checkbox@checked | checked

which fetches the value of the checked attribute on the checkbox with the id or name of checkbox and fails the script is the value is not checked.

In 1.0.10 though, that will fail even if it is checked. This is because checked is a boolean attribute and will now return either true or throw an exception saying the attribute doesn’t exist. Redoing the above step check that the boolean attribute is set results in:

 assertAttribute | checkbox@checked | true

Thankfully, most of the real-world interaction with boolean attributes is focused on checked, disabled, hidden and selected and in these cases using assertAttribute is not really the right thing to do. Instead, the Selenium API provides wrappers for you to use.

checked	assertChecked(locator), assertNotChecked(locator), verifyChecked(locator), verifyNotChecked(locator)
disabled	assertEditable(locator), assertNotEditable(locator), verifyEditable(locator), verifyNotEditable(locator)
hidden	assertVisible(locator), assertNotVisible(locator), verifyVisible(locator), verifyNotVisible(locator)
selected	assertSelected(locator, pattern), assertNotSelected(locator, pattern), verifySelected(locator, pattern), verifyNotSelected(locator, pattern)

Checking for the absence of a boolean attribute that doesn’t have a nice wrapper is a bit of a pain though. In this example I am checking that the boolean attribute multiple is not on the select element with the name elephants.

 assertEval | this.browserbot.findElement("css=select[name=elephants]").getAttribute("multiple"); | null

If you find yourself doing this very often, I suggest you wrap it up in a user-extension inside a plugin as something like

 assertBooleanAttribute | css=select[name=elephants]@multiple | false
assertBooleanAttribute | css=select[name=elephants]@multiple | true

Hopefully this addresses some of the eventual ‘why the heck did my script break!?!?!’ problems that will no double crop up once Selenium IDE 1.0.10 gets wider distribution.