Selenium – general

Blog: Selenium Vs … blog posts

Tue, 09 Jan 2024 00:00:00 +0000

The easiest way to clickbait a blog post about automated testing is to compare Selenium against another tool in the space with a catchy title especially when it talks down about the incumbent.

Unfortunately, this can lead to muddying the waters of which features are available in any of the products out there especially when we compare apples to apples.

Selenium has always been a great tool for browser automation. Fortunately for the project, it has become the tool of choice for testing web applications for nearly 2 decades. The area this project has focused on is building out the hard parts of browser automation that are increasingly difficult. Stable APIs and scalability of the infrastructure to run Selenium has always been the priority of the project. It hasn’t focused on how people test with it because there are very good test frameworks out there and having to do it for 5 different languages is a non-trivial amount of engineering effort.

However, some particular misconceptions regularly reappear across these blog posts.

It’s too hard to set up browsers and drivers compared to Playwright and Cypress

This used to be true in the past as you had to download the drivers. This wasn’t too bad for GeckoDriver and SafariDriver as they could handle browser upgrades gracefully. On the other hand, you need to update the drivers for Chromium-based browser for every new release.

For over a year now, Selenium handles this automatically. If it can’t find a ChromeDriver or EdgeDriver, it will download it using Selenium Manager. Since its first release it has improved a lot and it is now probably the best in class since the latest versions of Selenium will even download browsers if it can and use that. Compared to Playwright and Cypress you don’t need to update your dependency on Selenium to update browsers and drivers, you still use the same browsers as your customers, and switching versions becomes a breeze: you don’t also have to change the test framework you’re using. And, let’s not forget that it uses the browser that Google recommends you use for testing.

Setting up a test runner is hard work where Playwright and Cypress have it built in…

Well… maybe? Setting up E2E test frameworks with Selenium isn’t as difficult as some might suggest. The hard part really is making sure that the driver is in the right place and we’ve solved that as discussed above. Once that’s done, Selenium’s approach allows you to use whichever test runner you’re most comfortable with. If you’d like a “batteries included” approach, with Selenium tightly integrated with the test runner, then one of the many projects that use Selenium, such as SeleniumBase, Nightwatch, Serenity, and so on, might be the right tool for you.

One thing to note is that Playwright is the only multi-language browser automation framework like Selenium. However, if you don’t use TypeScript or JavaScript you will still need to do the setup of the test runner yourself. Some testing frameworks have plugins that automatically set up the fixtures you might need. In the JavaScript/TypeScript space if you really need a built-in test runner there are downstream projects like NightwatchJS and tangential projects like WebdriverIO. Downstream projects use our libraries and tangential projects have their own libraries but still follow the WebDriver standard.

Playwright and Cypress can do network interception and allow me to write event-driven code unlike Selenium

Selenium has been able to offer this since Selenium 4 came out. It’s so good that even Playwright suggest you use it for scaling your tests. The Selenium Project won’t be removing this anytime soon as we are dependent on WebDriver BiDi specification being implemented for those features to replace them. Even then Selenium has a history of trying to make sure that upgrades don’t break anything without sufficient warning. It’s why each language provides high-level wrappers, such as the NetworkInterceptor, that isolate your tests from the underlying technology being used.

Summary

As we have seen from the above Selenium is still as good as the products out there. One thing that is different for Selenium from Cypress or Playwright is that we’re a volunteer-driven project and not commercially backed. Want to help us out? Why not write a blog post about how you’re using the features above or post on social media how these features make your lives easier?

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: Year End Review 2022

Fri, 23 Dec 2022 00:00:00 +0000

It was an amazing year here at the Selenium project, and we wanted to remind you of some of the great things we accomplished.

In terms of releases, we continued to build on top of Selenium 4 which was launched in October 2021. This year we published v4.2, v4.3, v4.4, v4.5, v4.6, and v4.7. These releases included improvements, bug fixes, removal of deprecated functionality, improved error handling, updates of the underlying libraries, support for the latest Chrome DevTools versions to keep you in sync with new browser releases, but also new features.

We introduced the first (beta) version of the embedded Selenium Manager. The purpose of this feature is to help you manage your driver binaries without having to manually update them yourself each time a new version is released. We also introduced observability in the Docker-Selenium images. Another major new feature is native support for scrolling in the Actions API. But these are only some of the highlights of what we released. To get the details for each language we support, you can check out their corresponding Changelog pages: Java, Python, Ruby, Javascript, DotNet.

In terms of events and gatherings, in July our Selenium India Conference took place, this time online. It kicked off with an 8 talk pre-conference event, namely Selenium Lite. We then had a full day of workshops, followed by 2 days of conference. We had over 50 speakers and over 800 participants from around the world. The talks focused on Selenium, the Selenium ecosystem, automation, methodologies and best practices. In case you missed some of these talks, you can still watch them here.

We also held 2 test automation summits: one in San Francisco and one in Berlin. During these workshops the participants, together with some of the maintainers of frameworks from the Selenium ecosystem, built their Selenium based projects, added tests, new features and fixed bugs. During the first summit the participants focused on the BiDi protocol, while during the second one the focus was on Appium and mobile automation.

We are kicking off next year with a few surprises. The Selenium Conference in Chicago just announced the Speaker Lineup. Stay tuned for further details!

Many thanks to everyone who has contributed to the Selenium project for all their hard work this year!

And special thanks to all of you who are using, following and supporting the Selenium project.

From everyone here at SeleniumHQ, may you have the best holidays and an amazing new year. See you in 2023!

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: Scaling a Kubernetes Selenium Grid with KEDA

Fri, 19 Aug 2022 00:00:00 +0000

The Issue

If you have any experience with Selenium Grid and Kubernetes you will probably run into an issue with scaling. Kubernetes (K8S) works wonders for scaling up and down applications based on their CPU and Memory usage, but it is not so straightforward when it comes down to applications like Selenium Grid.

The issue is described quite well in this blog post. But in short, the Horizontal Pod AutoScaler (HPA) that is built into Kubernetes checks (by default) for resource consumption to determine if a deployment needs to be scaled up or down. This becomes an issue for Selenium Grid for a couple reasons:

The browser pods use a variable amount of resources depending on the demand of the current test. This means that all your browser pods may be in use but there isn’t enough CPU usage for the HPA to decide that a scale-up is needed, leaving tests waiting in the queue unnecessarily.
When Kubernetes decides to scale down a deployment it does so (for the most part) at random. You could have 10 tests running on 20 pods and need to scale down. More than likely at least one of the pods asked to terminate will still have a test running, resulting in connection failures.

How KEDA Helps

KEDA is a free and open-source Kubernetes event-driven autoscaling solution that extends the feature set of K8S’ HPA. This is done via plugins written by the community that feed KEDA’s metrics server with the information it needs to scale specific deployments up and down.

Specifically for Selenium Grid, we have a plugin that will tie into our grid to get the information it needs. Example of the used trigger:

triggers:
 - type: selenium-grid
 metadata:
 url: 'http://selenium-grid-url-or-ip:4444/graphql'
 browserName: 'chrome'

All of this gets saved as a Scaled-Object like so:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: selenium-chrome-scaledobject
 namespace: <namespace of your browser pods>
 labels:
 deploymentName: selenium-chrome-node-deployment
spec:
 minReplicaCount: 0
 maxReplicaCount: 80
 scaleTargetRef:
 name: selenium-chrome-node-deployment
 triggers:
 - type: selenium-grid
 metadata:
 url: 'https://selenium-grid-url-or-ip:4444/graphql'
 browserName: 'chrome'

As an added bonus KEDA allows us to scale our deployments down to 0 when there is no use, something the normal out-of-the-box HPA does not allow.

Check more details at the documentation for Scaled-Object in KEDA.

A full example of how to implement this is further down in the article but KEDA solves one of our two issues. Now we can properly scale up and down based on the actual load on the Selenium Grid. Unfortunately scaling down still results in the likely possibility that a pod is still running a test and is told to terminate before it can finish.

Using PreStop and Drain

To combat this we are going to use a combination of K8s PreStop and Selenium Grid’s Drain functionality.

PreStop allows us to set a command or chain of commands that is run to completion before the container is told to stop.
Drain tells the selenium browser pod to finish its current test and then shut down.

Together these look like so in our browser pod yaml:

spec:
 template:
 spec:
 terminationGracePeriodSeconds: 3600
 ...
 ...
 containers:
 lifecycle:
 preStop:
 exec:
 command: ["/bin/sh", "-c", "curl --request POST 'localhost:5555/se/grid/node/drain' --header 'X-REGISTRATION-SECRET;'; tail --pid=$(pgrep -f '[n]ode --bind-host false --config /opt/selenium/config.toml') -f /dev/null; sleep 30s"]

Breaking this down

terminationGracePeriodSeconds is set to however long you wish to give your pods to gracefully terminate before being forced. In this case I give the pods 60 minutes to finish their test when asked to terminate. If you are also scaling your cluster nodes as a part of this you may need to increase the termination grace period for your cluster nodes as well.
When the pod is told to stop, the PreStop command is ran first.
We curl the localhost of our pod to tell it to drain. The pod will no longer accept new session requests and will finish its current test. More information on this can be found in the Selenium Grid documentation.
We then tail the internal node process that will continue to run until the node has been drained.
After this we give the pod 30 seconds to finish anything else before giving the full termination command.

And with that our application can now safely scale down our selenium browser deployments!

From Start to Finish

Install KEDA

You need to use version 2.8.0 or later, you can find the latest version number at the Selenium Grid Scaler docs.
kubectl apply -f https://github.com/kedacore/keda/releases/download/<Version_Number_Here>/keda-<Version_Number_Here>.yaml

Create and apply your scaled object(s)

As described earlier your scaled object will look like so:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: selenium-chrome-scaledobject
 namespace: <namespace of your browser pods>
 labels:
 deploymentName: selenium-chrome-node-deployment
spec:
 minReplicaCount: 0
 maxReplicaCount: 80
 scaleTargetRef:
 name: selenium-chrome-node-deployment
 triggers:
 - type: selenium-grid
 metadata:
 url: 'https://selenium-grid-url-or-ip:4444/graphql'
 browserName: 'chrome'

You will need one of these for every browser you wish to scale.

Things to edit:

namespace should be the namespace that your selenium browser pods exist in
deploymentName are the name of your browser deployment
name (within spec) is also the name of your browser deployment
url is the url of your selenium grid
browserName is the name of the browser you are using
minReplicaCount and maxReplicaCount are the min and maximum pod count you want to have

If you plan to scale with Edge you will need at least version 2.8.0 of KEDA and will need to include sessionBrowserName as well in the trigger metadata:

triggers:
 - type: selenium-grid
 metadata:
 url: 'https://selenium-grid-url-or-ip:4444/graphql'
 browserName: 'MicrosoftEdge'
 sessionBrowserName: 'msedge'

This is due to a name change between the Edge sessions in the queue and the active sessions and is addressed through this pull request.

Once you have that ready just save it as a yaml file and apply with:

kubectl apply -f ./<scaled-object-file-name>.yaml --namespace=<browser_namespace>

Add PreStop commands to your browser pods

Set your terminationGracePeriodSeconds of your deployment to whatever the maximum time you wish to give the pods in order to terminate gracefully. Again you may need to also increase the grace period for your nodepool as well which will vary depending on your K8s provider.
Add the PreStop command to the container lifecycle spec:

spec:
 template:
 spec:
 terminationGracePeriodSeconds: 3600
 ...
 ...
 containers:
 lifecycle:
 preStop:
 exec:
 command: ["/bin/sh", "-c", "curl --request POST 'localhost:5555/se/grid/node/drain' --header 'X-REGISTRATION-SECRET;'; tail --pid=$(pgrep -f '[n]ode --bind-host false --config /opt/selenium/config.toml') -f /dev/null; sleep 30s"]

That is it, your Selenium Grid pods should now scale up and down properly without any lost sessions!

Blog: Test Automation Summit Berlin

Wed, 13 Jul 2022 00:00:00 +0000

Have you ever wanted to contribute to an open source testing project, but couldn’t figure out where to start? If so, fill out this form to apply for an invitation to join the Open Source Test Automation Summit on August 26 in Berlin, sponsored by Selenium and hosted by Sauce Labs. You can review the list of available projects below and select the one that you’d like to contribute to. We’ll be in touch soon if you are selected to join us.

Update 7/22/2022: Application deadline is July 28! We’ll contact everyone by Friday, July 29.

This will not be your typical workshop. This will be a working session with one or more maintainers of a given project to show you exactly what you need to know to contribute to that project. Selected participants will be required to bring a laptop capable of executing Selenium tests, including a working dev environment for the applicable programming language.

This is a new idea we’re trying out, so space is very limited. If there is sufficient demand we will consider doing more events like this in the future.

Objectives

At the end of the session you will be able to:

Build the project on your computer
Execute the existing test suite for the project
Write new tests for the project
Add a feature or fix a bug

Agenda (subject to change)

Start	End	Activity
0900	0930	Breakfast
0930	1000	Talk: “State of WebDriver Ecosystem”
1000	1100	Lightning talks about participating projects
1100	1200	Split into working groups and walk through projects
1200	1300	Lunch
1300	1630	Continue with working sessions
1630	1700	Wrap up
1700		Happy hour

Participating Projects

The following maintainers are will be present to assist you in working on their project:

Maintainer	Project(s)
Andrei Solntsev	Selenide
Boni Garcia	WebDriverManager
Christian Bromann	WebdriverIO
David Burns	W3C Web Platform Tests, Selenium
Diego Molina	Selenium
Filip Cynarski	FluentLenium
Jan Molak	Serenity/JS
Jani Mikkonen	Robot Framework
Nick Mokhnach	Appium
Ronald Brill	HTMLUnit Driver
Simon Stewart	Selenium
Titus Fortner	Watir, Selenium
Yevgeniy Shunevych	Atata

Update 7/20/2022: Ronald Brill, maintainer of HTMLUnit Driver will now be joining us!

Update 7/25/2022: Yevgeniy Shunevych, maintainer of Atata will now be joining us!

Update 7/26/2022: Simon Stewart, creator of WebDriver, will now be joining us!

Other Projects

Do you maintain an open source project in the WebDriver ecosystem?
Have you written a test framework that uses Selenium that is (or you want to make) open source?
Please fill out this form (provide additional relevant details in the comments), and we will be in touch about future events.

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: Improving & refining our Docs translations

Fri, 03 Dec 2021 00:00:00 +0000

A while ago, we started to make the Selenium documentation available in more languages. This, in an effort to offer a more inclusive environment for Selenium users who do not have English as their mother tongue.

This effort grew organically, and we got many pull requests adding content for different languages. Over time, some translations got to a very good state, and others didn’t get much attention. This brought the situation where 9 different languages are available in the documentation, but only a few add value to the readers.

To understand which languages are getting visits, we started using Plausible. After a few weeks, we combined the information collected by the analytics tool with the translated percentage per language, and we got the following:

Here’s the number of visitors on the landing page for a given translation in the past 2 weeks, and the percent of documentation pages translated:

Language	Visitors	Translated
ja	1,700	86%
zh-cn	1,500	86%
es	409	42%
fr	203	31%
pt-br	189	87%
de	88	65%
ko	79	68%
nl	22	6%

This shows that the most used languages (aside from English) are Japanese and Chinese, and that the language that has translated most of the content is Portuguese.

Based on this data, we decided to create a new role in the Selenium project: translators. This role will help the project keep in shape the different translations available. Together with that, we are also putting on hold the other available translations until we find volunteers for each language.

If you have any questions or comments, please reach out through any of all the available options shown at our support page.

Stay tuned for updates by following SeleniumHQ!

Happy testing!

Blog: Stepping Down, Stepping Up

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

The short version is that I’m stepping down as the Selenium project lead, and will concentrating on pushing WebDriver Bidi forwards. Fortunately, the Selenium TLC have already been steering the project for a while now, so it’s in excellent hands. With Selenium 4 now shipped, the project has a new energy and enthusiasm about it. The future is bright, and I’m looking forward to seeing what it holds.

The longer version? Well, that’s more personal. Let me start at the beginning….

On the 3rd January, 2007 I pushed the initial commit of “WebDriver” to a public repo. I helped with the Selenium 1.0 release, and at the same time made sure that WebDriver emulated the original Selenium RC APIs (in code that lives on to this day). In 2009, Jason Huggins and I merged the Selenium and WebDriver projects, and I took over the leadership of the project. I’ve been the lead for every version of Selenium since then, often being the person who tagged each release in source control, all the way up to the recent Selenium 4 release.

By the numbers, that’s

14 years of WebDriver
12 years of Selenium for me
- Though the first Selenium commits were in 2004
1 10 year birthday celebration
Approximately 130 Selenium releases.
I’ve landed just over 5100 commits
- Which is about 20% of all the changes made to Selenium over the years.
3 different source control systems
5 build systems
14 Selenium conferences
696 different people contributing to the project.

In a way, I blame Michael C for this. He and I worked together at ThoughtWorks in Australia, and had been working with HttpUnit. My assertion was that its API was fine. His was that it should be more Object-Oriented. To explore the idea, I started writing an OO wrapper around HttpUnit, and (of course!) Michael was right.

Or maybe it’s Joe Walnes who I should be talking about. At about the same, he’d been exploring a similar kind of design, but where my API had a Browser, his had the far better sounding WebDriver, and he was generous enough to allow me to use the same name in my next iteration of the idea.

Or, perhaps, it’s Paul Hammant and ThoughtWorks. Paul was the one who suggested Open Sourcing what was then “WebDriver” under the Apache 2 license, and ThoughtWorks supported the decision to make the code available to the world.

In any case, on that day in 2007, I was sitting on the sofa with a glass of red wine, creating the project on Google Code, and thinking (if I was thinking deeply at all) that it’d be nice to get the code out there, and in six months it’ll probably be over. There was absolutely no way I could dream that the project would grow far beyond me, emerging from the Cambrian explosion of the early days of web testing to become first an industry-wide de facto standard, and then, through the work done in the W3C, an actual standard. It’s the only browser automation API that all the browser vendors support.

During these past 14 years, Selenium has been one of the constants of my life. I joke sometimes that I’ve known it longer than my wife and my son, but is it a joke if it’s true?

Why spend that much time and effort on Open Source? On something that you give away for free? Because it’s just been so incredibly rewarding. I’ve had a chance to meet people from all over the globe, work with amazing people from a range of companies I’d never have a chance of working with normally, learn and practice skills I wouldn’t have had a chance to exercise, and to write code that makes people’s lives just a little bit easier.

Most importantly, Selenium has been the way that I’ve met some of the best friends I have in my life. I’ve been very lucky.

I’ve also been lucky to have met and been part of the Selenium community. The conferences and meetups have been a fantastic way to hear about how people are using the tool, and I am constantly impressed by how inventive and thoughtful people can be. The conversations I’ve had at those events have changed how I think about all sorts of things, and not just code. The IRC and Slack channels are vibrant and interesting places to be. There are folks who are there regularly who I’ve never met in person, but who I feel I could count as friends.

Who knew that Open Source could be the source of so much that makes a life bright?

But today, I’m stepping down as the project lead, and will be away from the project until summer, though (in the true spirit of this project), I’m not sure which year.

Why, if all I said above is true, am I stepping down?

The major reason is that the things I like to do, and that I’m good at, are not the things that the project needs right now. It would be hubris to believe that no-one else could do as good a job, particularly when I know how amazing so many people on the project are.

The other reason is that I’m tired. For the past 14 years, much of my free time, as well as hours within work, has been spent working on Selenium. There are other projects and interests I’d like to pour some energy into (just ask me how my Turkish lessons are going!)

In my absence, the project’s “Technical Leadership Committee” will continue to be setting the direction of the project. I’ve been listening to the discussions about where the project can go: it’s going to be brilliant.

That is, while I’m stepping down, the rest of the TLC will be stepping up. They’ve already been running the project for a while. They’ll continue the work we’ve started and carry it forwards and upwards. If you’re reading this, and want to get involved, step in and join the fun. Now’s the perfect time.

When I took over as lead of the Selenium project, Paul joked that he had thrown me the keys and run in the opposite direction. I guess it’s my turn to do that now!

Before finishing, I’d just like to say a heartfelt “thank you” to everyone who’s been involved in the Selenium project. To everyone who’s contributed in some way, or used the code we’ve written, thank you. To everyone who’s filed a bug, thank you too. To all the people who I’ve had the pleasure of so many conversations with, that I would never have met without Selenium, thank you. To my family, who’ve supported me and understood with endless patience that Selenium is a part of our lives, thank you. And to my friends on the project, an extra meaningful thank you.

I won’t be here, but I won’t be far. See you all soon.

Blog: Selenium 4 Release Candidate

Mon, 06 Sep 2021 00:00:00 +0000

We’re very happy to announce the first release candidate of Selenium 4. We’re shipping this for .Net, Java, Python, Ruby, and JavaScript, so if you’re using any of those languages, go and grab it from your package manager of choice!

This release is the result of a lot of work by the Selenium team project, but most importantly, all the Selenium community who tried our beta releases, and gave us great and valuable feedback.

#Selenium 4 Release Candidate for #ruby is now available! There should be fewer problems running against latest versions of browsers now than with Selenium 3. Please update and let us know of any problems so we can get the production release out the door. https://t.co/JWbwDRPcj4
— Titus Fortner (@titusfortner) September 1, 2021

So, big news: #Selenium 4.0 RC1 has just been released! The .NET bindings are available via #NuGet, or you can find them at our new binary release point, https://t.co/CSNK7K47ue. We're closing in on a final, stable 4.0 release, so if you haven't tried it before now, you should!
— Jim Evans (@jimevansmusic) September 1, 2021

#Selenium 4 RC1 is out! The #python bindings are available at https://t.co/B4zKI6JQkA pic.twitter.com/kMlDM4ad7I
— David @automatedtester@mastodon.social (@AutomatedTester) September 2, 2021

Hurrah! #selenium4 RC1 is out, and the Java bindings have been released! Grab them from your favourite maven repo, or download the binaries from https://t.co/XUcv7RzbzL pic.twitter.com/E9T1ZTZ9jd
— Simon Mavi Stewart (@shs96c) September 2, 2021

@SeleniumHQ 4 RC 1 is out! This means that Selenium 4 is getting closer and closer 🎉🎉
Try out the new Grid through our @docker images -> https://t.co/lGUrZAQneJ pic.twitter.com/BzZxPn3p0y
— Diego Molina (@diegofmolina) September 6, 2021

One thing you may want to do to get ready for the update (which you can do before updating the dependency itself!) is to update the drivers you need. In particular, please update geckodriver to 0.29.1 or later.

Most of the new features in Selenium 4 are mentioned in this blog entry, but the main highlights are:

Relative locators, for finding elements using terms that make sense to us humans.
The ability to intercept network traffic
Authentication with basic or digest authentication.

If this sounds interesting, please download the release candidate from your favourite package manager (maven, nuget, npm, pip, or the gem), or directly from the Selenium site.

Blog: All Selenium downloads are now available on GitHub releases

Tue, 24 Aug 2021 00:00:00 +0000

We announced on a previous entry our decision to move all binaries from Google Storage to GitHub releases. Today, we would like to announce that this work has been completed and all binaries are also available to be downloaded in each one of the releases we have done in GitHub.

In addition to that, all links on our downloads page have been updated, as well as all references to Google Storage in the Selenium code base.

Please note that all past releases will be available both in Google Storage and GitHub releases, but new ones will only be present in GitHub releases. We recommend everyone to modify your download scripts to keep all tooling up to date.

If you have any questions or comments, please reach out through any of all the available options shown at our support page.

Stay tuned for updates by following SeleniumHQ!

Happy testing!

Blog: Selenium downloads will move to GitHub releases

Thu, 19 Aug 2021 00:00:00 +0000

Thanks to Google, Google Storage has been the central place where we have been able to upload all binaries created for each Selenium release, and the place where the Selenium community can download them from. To do so, all people needed to do was visit our downloads page, find the release, and download from there!

The Selenium project hosts its source code on GitHub, and people who are familiar with GitHub know that they can go to the “release” page there to find any downloads for each release of a project.

Rather than hosting the downloads in two places, the Selenium project has decided to host everything on GitHub. We’ll still have links from the download page, but rather than pointing to Google Storage, these will now point to the downloads for each corresponding release tagged on GitHub.

All past releases will be available both in Google Storage and GitHub releases, but new ones will only be present in GitHub releases.

If you are a watcher of the Selenium repo, please note that there will be some noise in your inboxes. We need to create releases for old tags in order to upload the binaries to the release (as is the way GitHub releases work), and we expect to complete this in the next couple of weeks.

If you have any questions or comments, please reach out through any of all the available options shown at our support page.

Stay tuned for updates by following SeleniumHQ!

Happy testing!

Blog: The Selenium website has a new look!

Mon, 09 Aug 2021 00:00:00 +0000

We have been working hard during the last few weeks redoing our website. Today, we are very happy to share it with the community and we are hoping to get as much feedback as possible!

We did a major revamp to our website two years ago. However, this revamp had some “technical debt” in it…

We're happy to announce that we have (finally!) refreshed our site. Head on over to https://t.co/0xAiKdHrPj and have a browse! Thanks to @diegofmolina and @manoj9788 for making this happen.
— Selenium (@SeleniumHQ) November 12, 2019

We use Hugo to generate our website, and to build a website with Hugo, one normally needs to select a Hugo theme. Our previous website was being built using two different Hugo themes, which was less than ideal. Having two Hugo themes was hard to maintain and accepting contributions was tricky in some cases.

This new website version is using the Docsy theme, made by some folks at Google and used by other popular projects such as Apache Airflow and Kubernetes. Using Docsy helps us to focus more on the website’s content rather than spending lots of time maintaining the underlying details of it.

We all hope you will like the new look and please check our contribution guidelines if you want to contribute to the Selenium website.

Happy testing!

Blog: IRC channels are moving to Libera.chat

Thu, 20 May 2021 00:00:00 +0000

Yesterday, 19 May 2021, all the staff of Freenode, the IRC network, collectively resigned as staff because of what they felt was a hostile takeover.

Freenode has always been seen as the home of Free and Open Software, so it was natural that you could find us on the #selenium channel there. To maintain this openness, and inclusivity, we are moving our IRC Channel over to Libera.chat. It is has been created by the team that previously maintained Freenode.

We are in the process of moving our Slack-to-IRC bridge over and hopefully the matrix bridge will be created soon so that we can have a free and inclusive project on the new IRC Servers. There may be a few hiccups so if you could bear with us.

If you have any questions please feel free to reach out to me on twitter or on one of the chat protocols we support.

Finally, thank you to “Milen from Bulgaria” for helping secure the channel for us on Libera.chat.

Blog: Selenium 4 Beta 1 Released

Mon, 15 Feb 2021 00:00:00 +0000

We’re very happy to announce the release of the first beta of Selenium 4. We’re shipping this for Java, .Net, Python, Ruby, and JavaScript, so if you’re using any of those languages, go and grab it from your package manager of choice!

This has been the culmination of a lot of work by so many people, not only the project TLC, but also of literally hundreds of people: 205 since we released Selenium 3.141.59, at the last count. A big thank you to everybody who’s helped make this possible!

So, what’s changed since Selenium 3? The answer is both “not much” and also “almost everything”.

By “not much”, I mean that if your tests are working with Selenium 3 right now, you should be able to just upgrade your dependency to Selenium 4. You will find that things that were marked “deprecated” are now gone, but the advantage of the long time between the last Selenium 3 release and this is that you’ve had plenty of time to try and find alternatives.

If this doesn’t work, please let us know! We’ve worked hard to ensure compatibility between the releases, but it’s possible we may have missed some things.

By “almost everything”, I mean that under the covers there have been substantial changes. We’ve rewritten the Selenium server to allow it to work not only in the familiar “standalone” and “hub and node” modes, but also in a new “distributed” mode, which makes it signifcantly easier to deploy to something such as Kubernetes in a way that scales well.

The new server is also wired up with support for OpenTelemetry and exposes a GraphQL endpoint, so that figuring what’s going on in the Grid, and tracking down what’s gone wrong if something happens, is easier than ever.

Not all the changes are server-side. We recently wrote about the new features in Selenium 4 that you can use in your tests, but some of the main highlights are:

Relative locators, for finding elements using terms that make sense to us humans.
The ability to intercept network traffic
Authentication with basic or digest authentication.

We’ll be telling you more about these features in later blog posts, and as we improve our documentation.

If this sounds interesting, please download the beta from your favourite package manager (maven, nuget, npm, pip, or the gem), or directly from the Selenium site.

Blog: New Tricks in Selenium 4

Fri, 05 Feb 2021 00:00:00 +0000

In the fourth and final post in his series, Simon Stewart continues talking about what’s coming in Selenium 4 and reviews what’s new in the Selenium Grid.

We’ve covered a lot of ground in the past few blog posts, including how to contribute to the project, and some details of what you can expect as a Selenium user. But there’s more to Selenium than just the APIs you use to write your tests, and one of the big features we’ve not covered yet is the refreshed Selenium Grid: a mechanism that allows you to distribute your tests across a fleet of machines.

Before going further, it’s always nice to acknowledge where we’ve come from, not only because it’s interesting, but also because it helps explain the “why” of the refreshed design.

Way back in the mists of time (2008), Jennifer Bevin and Jason Huggins worked on a system called the Selenium Farm at Google. This was a fleet of machines sitting in a cupboard somewhere that allowed you to run the original Selenium protocol. This was, of course, at Google scale, so there was more than one cupboard :)

This allowed people at Google to distribute their tests and scale out beyond their individual machines. This was such a great idea that when Jennifer talked about the Farm at a Selenium meetup, Philippe Haringou (then at ThoughtWorks) decided to write an Open Source implementation of the same thing, which he called “Selenium Grid”.

Selenium Grid was a lovely piece of technology, but it had one drawback: it only spoke the original Selenium RC protocol. That was fine, but WebDriver spoke a different wire protocol, which was called the JSON Wire Protocol, and folks wanted to be able to use both Selenium RC and WebDriver at the same time.

This is where Francois Reynaud enters the picture. He was working at eBay, reporting to Michael Palotas, and he had written something like the original Selenium Grid, but which also worked with the JSON Wire Protocol. They very kindly contributed that work to the Selenium project, and it formed the basis of the Selenium Grid 2. We decided at the time that the Selenium standalone server would effectively be a “grid of one”: it would have everything you needed in it to set up a Selenium Grid, as well as to work as a single standalone server. Merging the code and getting it stable took a while, but thanks to the efforts of Francois, Kristian Rosenvold, and many others, we merged Grid 2 into the main Selenium project and shipped Selenium 2 in 2011.

Even if 2011 doesn’t feel that long ago, the modern world has changed quite significantly. In 2011, we didn’t have Docker. We didn’t have Kubernetes, we didn’t really have AWS. So, the Selenium Grid didn’t know that those things were coming in, and wasn’t written to take advantage of them. Fortunately, we did have virtual machines back then, and the Grid 2 had been designed to be able to support them.

This was the hook that an excellent project called Zalenium. Developed by Diego Molina, Zalenium added a really nice UI and support for Docker and Kubernetes—all built on top of the Grid 2. This has allowed the Selenium Grid to continue to be relevant and useful to this day, which is an amazing achievement.

But, like I said, it took us time to stabilise Grid 2: about six months of hard work, largely led by Kristian. That’s because while Grid 2 was sophisticated, the code was hard to read and hard to maintain—and very few people could do that. Worse, the merging of the Grid 2 and the original Selenium server was pretty crude; effectively there were two separate servers shipped in the same binary. This led to problems occurring in the Grid but not when run in standalone mode, and vice versa.

With Selenium 4 we’ve decided to bite the bullet and address these three concerns. Firstly, we want something that was easier to work on and maintain. Secondly, we want to merge the servers into a single unit. Thirdly, we want something that will take advantage of the world of modern infrastructure we have available to us now, not just in the form of Docker and Kubernetes, but also to be able to use emerging technologies such as distributed tracing.

To do this, we looked at the functionality the Grid provided, and to model each piece as a component that we can either run “in memory” (allowing us to have a single standalone server), or in a more distributed way, allowing the “hub and node” architecture that we’re familiar with from the original Selenium Grid, to a fully distributed design.

The first component is the “router”. It serves as the entry point to the Grid. You can expose it to the internet and it directs requests to the Grid. It’s designed to be stateless, and so you can add more to Grid as you find you need to.

When the router sees a new session request, it places it on a “session queue.” The session queue is read by a component called the “distributor,” which maintains a model of all the places in the Grid where a session could be run: we call them “slots”. The slots are hosted by components called “nodes,” and each node can have one or more slots. When the distributor pulls a new session request from the queue, it identifies the most appropriate slot to use, and forwards the request to the node which owns the slot. Once the node has started the session, the distributor puts the session ID and the URL of the Node that is running the test into the “session map”—you can think of the session map as being a simple map of a session ID to URL—and the new session response is sent back to the waiting test.

Requests for running sessions (that is, for most webdriver calls!) are handled slightly differently. The router will use the session map to look up which node to forward the request to, avoiding the need to involve the distributor entirely. This means that you can just keep adding nodes to the Grid, and there are fewer bottlenecks in the architecture to slow your requests down.

Conceptually, there are these five moving pieces within the Grid. But there’s actually a sixth one, which is a message bus. The five Grid components communicate internally through the message bus, but the actual components that you need to think about when you’re thinking about the Grid are the Router, Session Queue, Distributor, and Nodes.

When you run Selenium Grid 4 in “standalone” mode, you actually get a “grid of one”. We wire up all these components in a single process, but they’re all still there.

You can also run it in the traditional Hub and Node approach that you’ve seen with Selenium Grid 2, where you fire up a Hub and a Node and it registers. If you’ve used Selenium Grid recently, that’s probably the architecture that you’re familiar with. In this case, most of the components (the router, session queue, and distributor) are running in the Hub, and the Nodes run the sessions themselves.

What’s new with Grid 4 is that you can go into a fully distributed mode if you want to. Typically, you would want to use something like Kubernetes for this, and some of the key components are designed to store data using a database or Redis for better reliability and scalability.

Something to note is that when running a distributed Grid, it becomes really difficult to figure out what is happening, particularly when something goes wrong. To alleviate that problem, we have adopted Open Telemetry to bring observability into the Grid. What do we mean by observability? It simply means that we want to be able to see everything that happens.

Finally, we’d like to expose information about the running Grid in meaningful and useful ways. The original Grid supported both JMX (a Java management API) and an HTML-based console. While nice, this didn’t make it easy to query specific areas of the Grid that you might be interested in that weren’t surfaced by the UI (for example, how many slots are available, or to find out which node a particular session is running on) To provide more flexibility, we’ve chosen to provide a GraphQL endpoint for the Grid. To ensure that GraphQL endpoint is sufficiently flexible, we’re building the new Grid console using it. That should allow you to also extract useful metrics and information from the Grid for your monitoring needs.

Those are some highlights of the new Selenium Grid. What are you the most excited about?

This was originally posted at https://saucelabs.com/blog/whats-coming-in-selenium-4-the-new-selenium-grid

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: New Tricks in Selenium 4

Wed, 16 Dec 2020 00:00:00 +0000

In the third post in his series, Simon Stewart continues talking about what’s coming in Selenium 4 and reviews some of the tricks in the new release.

In my last posts, we talked about how to contribute to Selenium, and why we’re bumping the version number to 4. That’s enough preamble! Today, we’ll cover some details about the new tricks and capabilities that Selenium 4 offers.

Finding Elements, and Relative Locators

You know, finding elements on a page can be really difficult. I’ve seen loads of people using very complicated XPATH expressions, and trying to figure out complex CSS selectors and things like that. There have been whole talks about the subject at SeleniumConf. Surely there must be a better way to do this?

Think about how we describe where an element is on the page. Think about how you’d do this over the phone. You’d never talk about the raw DOM, “Ah, find the fifth DIV element nested inside the SPAN with an ‘id’ of ‘foo’”. You’d just never say that! Instead, you’d say something like, “just find that thing above that image, and to the right of that link,” when talking about where things are located on the page.

A long time ago, a project called Sahi started to locate elements like this. Sahi had Relation APIs, which are a lovely way of finding elements, and it was very, very fluent and pleasant to use. When I was starting WebDriver years ago, I was talking with Narayan (creator of Sahi) and I promised him that I was going to hold off implementing this flagship feature of Sahi. It was something that was lovely, but it was also something Sahi was rightly proud of. However, there are now other tools, such as Tyco, that are implementing this style of API, so it seems like the time is right to do the same in Selenium. In Selenium 4 we call them “relative locators.” You may sometimes see us refer to them as “friendly locators,” since the initial implementation called them that, but “relative” better describes how they work. We have a handful of them: near, above, below, left of, right of. They allow you to talk in human language about where an element is on a page.

Looking at the future, we are also planning to enable users to add new types of locators, not only on the, on the client side, but also to the Selenium Server. For example, although JS UI frameworks come and go (anyone else remember using jquery?), it’d be nice to be able to add a custom locator for the current tools people like, such as React.

Authenticating to Web Sites

One feature that people have been asking for since we started the project has been the ability to authenticate to a web site. Previously, you could do this by crafting the URL the browser went to properly, but this leaks credentials to any man-in-the-middle and leaves them in server logs, so browsers have slowly removed this piece of functionality. That’s unfortunate, since it’s something that we know people frequently need to do in their tests. In Selenium 4, we now offer a mechanism to register a username and password that can be used to authenticate against these sites.

Intercepting Network Traffic

A common complaint of Selenium tests is that they’re slow and flaky. While the bindings to the browser are excellent, and fully described by the W3C WebDriver spec, it is true that any end-to-end test is likely to suffer more flakiness than a simple unit test—there are just more moving parts, and more possibilities for things to go wrong.

One way to resolve this issue is to stub out the backend of the application, intercepting network traffic in the test and returning pre-canned responses. Tools such as mountebank make this easy for API testing. Wouldn’t it be nice if there was a similar tool for Selenium?

With Selenium 4, we now provide a mechanism to do this, using the NetworkInterceptor (well, that’s what we call it in the Java bindings). Pass it your WebDriver instance, and it’ll be called every time the browser is about to make an HTTP request, allowing you to return almost anything you want

The Chrome Debugging Protocol

As I mentioned previously, one of the nice things about Selenium 4 is our work to ensure a stable and modern user-facing API. What does this mean? To start, we need to acknowledge that after a long time there’s now competition back in the browser automation space. Notably in the form of Puppeteer and Cypress, and taking a step back, what do they offer? They build upon the Chrome DevTools Protocol (CDP)>, which is a protocol developed to enable a debugger inside Chromium-based browsers.

Because of what it was designed to do, it is a chatty protocol, and not a user-facing API that allows you to introspect into the browser. Worse, introduce a network hop between the test and the browser, this chattiness leads to slower tests as the network latency increases. That is why tools such as Puppeteer want you to run on the local machine. That’s great for the speed of an individual test, but makes parallelisation harder, as you can’t use services such as Sauce Labs easily.

To complicate matters, because the CDP is designed as a debugging protocol, it can change with no notice between versions. That’s why Puppeteer and Cypress are tied to specific versions of browsers, and that causes a dilemma for you as a test author: how do you test on multiple versions of a browser? Updating the test API to get a different browser can lead to you no longer making valid API calls. Not doing so ties you to a potentially outdated version of a browser.

Despite this, using the CDP opens up a host of possibilities, and that’s why we’ve added support for it in Selenium 4. In fact, some of our new features are built on top of it (though we hide the details!)

But we’ve also gone further that just adding basic support. Selenium 4 can support multiple versions of the CDP at the same time, meaning you can test with both the current and beta versions of Chromium-based browsers without needing to rewrite tests. We do this by providing an “idealised CDP”, which is stable and covers the features we feel tests need. If that idealised view of the world isn’t enough for you, we also expose the raw CDP APIs too, giving you flexibility to choose what’s best for your tests.

We’re feeding this experience into the new W3C WebDriver Bidi specification, which is helping make that a better fit for testers.

I am leaving out of this post all the details related to another important trick in Selenium 4, the new Selenium Grid, which I will cover in the next post. Stay tuned!

This was originally posted at https://saucelabs.com/blog/new-tricks-in-selenium-4

Blog: What’s Coming in Selenium 4: Why The Major Version Bump?

Tue, 10 Nov 2020 00:00:00 +0000

In the second post in this series, Simon Stewart continues talking about what’s coming in Selenium 4 and why this release has a major version bump.

In my last post, I shared a bit about how the Selenium project works overall. Now, let’s start talking about Selenium 4 and what’s coming. One thing I think I should clear up is “why the major version number bump?”

Sometimes I joke that the major reason for the version number bump is that while the digits of Pi are infinite, when we went from 3.14 to 3.141, people got a little bit upset. Moving to 3.141.5 and then 3.141.59 was as far as we wanted to push that particular idea :)

More seriously, the first reason is that we have a revised Selenium IDE. Years ago, this used to be Firefox only because it used the XPI extension mechanism (which was specific to Firefox). It’s now a web component, and you can download it for Chrome, Firefox, and anything else that supports Web Components. There is currently work to rewrite it as an Electron app, which will allow us to make better use of the native OS the IDE is running on. That work was largely pushed forward by developers working at Applitools. They started from a base of the original Selenium IDE that had been migrated to use Web Components by a company called SideX. It’s been a fantastic example of the community working together well.

Secondly, we have fully adopted the W3C WebDriver protocol, and have dropped support for the original home-grown wire protocol. The way that Selenium communicates with a web browser is via a wire protocol that’s effectively just JSON over HTTP. Originally this grew organically as we figured things out, and we tried to make browsers do what we needed them to. That original protocol is known as the JSON wire protocol because it spoke JSON over the wire (and we’re not great at coming up with very original names).

That original protocol was the base for the W3C WebDriver protocol, which smoothed some of the rough edges, and brought some much needed consistency to the protocol. The two major areas the standardised protocol improved on included session creation, where we removed considerable ambiguity, and by providing a far richer API for specifying user actions.

So what does this adoption of the W3C protocol mean for you? I’ll be honest: it probably doesn’t mean much to you at all. If you’re using a modern browser (released over the past couple of years), you will find that actually you already speak the W3C protocol with Selenium 3.

So who does care about the protocol dialects? When we talk about companies like Sauce Labs who provide Selenium as a service—they care about it. The ecosystem is ready for this next step, because the technical folks at these companies have ensured that they understand and comply with the W3C protocol, and folks from the Selenium project have been there offering help and advice as needed.

One of the other nice things about Selenium 4 is that we’ve done our best to ensure a stable user-facing API. That means when you upgrade your project from Selenium 3 to Selenium 4, it should be a drop-in upgrade. You just change the version number, recompile and you should be done.

There are a few caveats that you should be aware of, however! The major one is that if in the last version of Selenium 3 a method was deprecated, it’s now probably gone. We’ve taken the opportunity of a major version bump to delete them and clean up the behind-the-scenes internals people don’t normally get to see. If you’re a software developer, you may recognise this as us paying off some of our technical debt :)

Stay tuned for the next post, where I’ll go over some new tricks in Selenium 4.

This was originally posted at https://saucelabs.com/blog/whats-coming-in-selenium-4-why-the-major-version-bump

Blog: What’s Coming in Selenium 4: How Can I Contribute?

Mon, 02 Nov 2020 00:00:00 +0000

In this new blog series all about the upcoming release of Selenium 4, Simon Stewart will cover how the Selenium project works, who is involved, how you can get involved, and a sneak peek at what’s new in Selenium 4.

As the lead of the Selenium project, I wanted to kick off a new blog series leading up to the release of Selenium 4. During this series, I’ll talk all about how the Selenium project works, who is involved, how you—yes, you!—can get involved, and we’ll get a sneak peek at what’s new in Selenium 4. I’ve been speaking about this off and on for a while, but now the 4.0 release is looming I wanted to start sharing in more depth.

In this first post, we’ll start off with a brief discussion about how the Selenium project itself runs and who does what, because that’s a really helpful piece to understand how and why things happen the way they do on the project. In future posts, we’ll look at the new IDE, and then we’ll talk about Selenium 4 in more depth, including the fact that it should be a drop-in replacement for you. I’ll also review some new features that we’ve added to Selenium 4, and talk a bit about the modernized Selenium Grid. So let’s get started!

About the Selenium Project

Selenium is an Open Source project. It’s run under the aegis of the Software Freedom Conservancy (SFC). The SFC is a group dedicated to pushing forward Free and Open Source software. Besides Selenium, they have a handful of projects you may have heard of, including Samba, Mercurial and Git. The SFC allows us to focus on writing code and fixing bugs by handling all the legal and financial stuff we’re not good at. They’re the ones that help us negotiate contracts for when we want to run SeleniumConf, for example.

Acting as a bridge between the project and the SFC is the Project Leadership Committee (PLC). Currently, it’s made up of Jim Evans, Alexei Barantsev, Marcus Merrell, Manoj Kumar, and myself. What do we do? Effectively, the PLC is about providing a smaller group of people for the SFC to talk to when decisions need to be made about funding a conference, or how best to respond to sponsorship agreements. Because we like to do as much work in the open as possible, you can find us on the #selenium-plc Slack channel, and almost every conversation and topic is discussed here.

One of the key qualifications for being on the PLC is a demonstrated commitment to helping the Selenium project improve and succeed, and we recognise that the project is more than just “code.” It’s a community, and the make up of the PLC reflects that.

The Technical Leadership Committee (TLC) includes the people who set the technical direction for the project. If you come over to the Selenium Slack, you can find the #selenium-tlc channel, which is where a lot of the technical conversations happen for the project. The TLC includes Jim Evans, Alexei Barantsev, David Burns, Diego Molina, Titus Fortner, and me.

How do you get on the TLC? Although the project governance document goes into more detail, it can be summed up as simply as someone who’s demonstrated technical leadership on the project, over an extended period of time. Just as with the PLC, being on the TLC doesn’t give someone more authority, but they’re the ones who can merge PRs, and who can (if need be) commit directly to the tree.

Again, the TLC tries to do as much work as possible in the open. If you’re ever interested in watching the design discussions, or asking why a bit of the Selenium code base is structured the way it is, then come and join us in the #selenium-tlc Slack channel. There’s normally someone from the project there who’ll be able to answer your questions!

I wanted to share how the project works for one simple reason: to highlight one of the really important things with Open Source, which is that anyone can contribute! You don’t need to be throwing code around in order to be contributing, and you don’t need to be special in order to contribute your time and effort.

So obviously there’s the people running the projects and writing code, but we couldn’t do that all on our own. Every release includes contributions from a variety of people, not just the core development team. Also, we’re always happy to accept patches. If you’re not quite sure where to start, I recommend you head to our GitHub page and take a look at the project tab. That’s where you can see the things that need to be done and what we’re working on.

The other way to get involved is the way that everyone used to get involved with Open Source, which is by what’s known as “scratching your own itch”. It’s if there’s something about the project, something about the product you think could be a little bit better, download the source, edit it, and then send us a PR.

We encourage you to get involved and contribute! On the Selenium website, there is a page that outlines in detail the steps to join the Selenium team. Join the Selenium Slack channel to interact with us and ask questions. If you want to discuss something, or if you don’t understand why the code is written the way it is, feel free to come on to that Slack channel and talk to us. Also, if you’d like to see how the decision making is made, then please do feel free to come on to the #selenium-tlc or the #selenium-plc channels to see those groups. Because we’re Open Source, we try and do everything in the open.

If you’d like to put faces to people’s Slack or IRC handles, then please note that there’s a regular team meeting every other Thursday on Google Meet at 4:30pm (UK time!) We tend to just chat and discuss everything from the project to the weather, but that’s a great way to get to know people a little better! :)

Finally, if you’re having trouble getting to grips with the Selenium code base, then please do come and ask us for help. We’ve done our best to make the on-ramp as easy to take as possible, but the project can seem complicated and daunting when you’re getting started. We’re here to help!

I hope you enjoyed this intro to the Selenium project. Next week, we’ll talk about why the major version bump to Selenium 4. Stay tuned!

This was originally posted at https://saucelabs.com/blog/whats-coming-in-selenium-4-how-can-i-contribute

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: Selenium 4.0 Alpha 6 is out!

Mon, 01 Jun 2020 00:00:00 +0000

We are very pleased to announce the release of Selenium 4.0 Alpha 6.

All the information can be seen in different tweets from the project contributors, here they are all in one place:

Happy Friday! I've just pushed Selenium 4.0a6 for Java. There's a lot of nice changes:

* Full remoting of the CDP protocol across the Grid
* The skeleton of our GraphQL support
* Better configuration options, especially for Nodes, via TOML
* A bajillion improvements & fixes

1/5
— Simon Mavi Stewart (@shs96c) May 29, 2020

As ever, this release is the product of hard work and contributions not only from the core team (special thanks to @barancev and @diemol. You've done amazing work!) but also from a host of other people. In that spirit, I'd like to thank… 2/5
— Simon Mavi Stewart (@shs96c) May 29, 2020

In no particular order:

* Amit Bhoraniya
* @bongosway
* Gerry Gao
* Sridhar Upputuri
* John Chen
* @alb_i986
* Rahul Shah
* @ulfjack

I've linked to the twitter handle where I know it. Give 'em a high five! Selenium wouldn't be possible without the help of the community! 3/5
— Simon Mavi Stewart (@shs96c) May 29, 2020

I'm hoping that the next alpha will be the last alpha. The "big ticket" items remaining are:

* Provide nice APIs to take advantage of the CDP
* Flesh out the GraphQL support
* A nice UI to take advantage of the GraphQL endpoint
* Robustness work in the Grid

4/5
— Simon Mavi Stewart (@shs96c) May 29, 2020

You can come and join in the fun by either heading over to the GitHub project and picking a task (https://t.co/2ifj6CkeEV) or (and!) coming to have a chat on Slack https://t.co/4aEDqyI6gq 5/5
— Simon Mavi Stewart (@shs96c) May 29, 2020

I have just tagged #Selenium 4a6 on GitHub. It's got a lot of nice cleanups as we edge closer to a proper #Selenium 4 release!
— David @automatedtester@mastodon.social (@AutomatedTester) May 28, 2020

selenium-webdriver 4.0.0.alpha6 has just been released. The biggest change is an experimental support for Chrome DevTools protocol! Read more in changelog https://t.co/1l2XYkaEfB.#selenium #ruby #devtools
— Alex Rodionov (@p0deje) May 28, 2020

Happy hacking!

Blog: Selenium IDE Is Dead, Long Live Selenium IDE!

Mon, 06 Aug 2018 00:00:00 +0000

In August of 2017 Simon shared the bleak, hard news that as of Firefox 55 Selenium IDE would no longer work. Selenium IDE (or as we’ll refer to it from here on out – the Legacy IDE) was, and is, dead.

Since then quite a lot has happened with the IDE. We have a new version of it which we are referring to as… Selenium IDE!

It is currently in “alpha” and available for use in both Chrome and Firefox.

In his post Simon also mentioned “the fine people at Applitools“. This includes Tomer Steinfeld, Dave Haeffner, and Doron Zavalevsky. Together, along with contributions from the rest of the Selenium community and the SideeX project, we have been able to get the new Selenium IDE out into the wild. We are also working to close the gap on feature parity with its predecessor along with adding some much needed enhancements to the tool (more on that in future posts).

We’d love for you to give the new IDE a try and let us know what you think. Visit either the Chrome Web Store or Firefox Add-ons to install it. For info on how to use the tool, you can check out the getting started documentation on Selenium HQ.

If you have any questions you can find us on the Selenium Slack/IRC chat channel. Think you found a bug? File an issue. Want to contribute? Take a look at the project on GitHub.

Happy Testing!

Blog: Firefox 55 and Selenium IDE

Wed, 09 Aug 2017 00:00:00 +0000

The bad news: from Firefox 55 onwards, Selenium IDE will no longer work.

The reasons for this are complex, but boil down to two main causes:

Browsers are complicated pieces of software that are constantly evolving. Mozilla has been working hard to make Firefox faster and more stable, while still retaining the flexibility and ease of extension that we’ve come to know and love. As part of that process, Firefox is switching extensions from the original “XPI” format, to a newer, more widely adopted “Web Extension” mechanism.
The Selenium project lacks someone with the time and energy to move the IDE forwards to take advantage of the new technologies.

Selenium is one of the most widely used pieces of testing software there is. Despite this, the team of people regularly contributing is small: since the start of the year, there are only 11 people who have made more than 10 commits, with two people accounting for more than half of those. Since 2016, only one person has been maintaining the IDE.

Selenium is an Open Source project. None of the core contributors — not the IDE maintainer, not the language binding owners — are paid to work on work on it. They do it because they love working on the code, and they typically do it in their “copious free time”. The IDE maintainer has had almost none of that to spare. We should all be thanking that committer for his time and effort. Thank you, Samit!

So what can we do to move forward? The first thing is that there are now a wealth of tools that are stepping up to fill the gap. You should go and have a look at them. The second thing is that there is an effort to rebuild IDE using modern APIs, to be usable across more than just Firefox. The fine people at Applitools are helping with this effort.

The third thing? That’s you. You could help us.

If you believe that a friendly UI for quickly recording and playing back tests is a useful Open Source tool, then please come and join us! The main technical discussions are happening on the #selenium IRC channel. If you’d prefer Slack, you can join us on that too. Or there’s the ever useful selenium-developers mailing list. Come onboard. We’d love your help, and IDE is a wonderful thing to contribute to!

Blog: Hacking with IntelliJ

Wed, 08 Feb 2017 00:00:00 +0000

Jetbrains have a programme for Open Source projects which allows them to receive IntelliJ IDEA licenses. As part of that programme, which the Selenium project has participated in for many years, they’ve asked us to provide a fair and balanced review of IntelliJ. I’ll attempt to do that, and I’ll try and state my biases up-front so you’re aware of them.

I’ve been using Jetbrain’s IntelliJ to hack on the Selenium code since I started working on it slightly over ten years ago. It’s still my favourite IDE for my Java work, and it’s plenty of fun to use. For some time, I’ve been using the (free) Community Edition, which is ample for many coding needs.

Most of my work is in Java, and that’s where I know IDEA best. I dabble in Ruby and Python, and I’ve written a reasonably large amount of Javascript, all in IDEA.

The Pros:

In common with other good IDEs, IDEA has the ability to work seamlessly with many different languages. If you’re a polyglot programmer, being able to stay in the same tool for much of your work makes life a lot easier. On the Selenium project, we use Java, C#, Ruby, Python, and Javascript extensively. I don’t do any C#, and I mainly focus on Java, but the support for JS, Ruby, and Python is lovely and seems to work well. The built in type detection and code navigation features are impressive (particularly for untyped languages such as JS)

Of course, the feature that made IDEA so awesome in the first place is the range of refactoring options it offers. These are great, and always have been. One nice feature I’ve noticed as we move to a Java 8 future (finally!) is that it offers suggestions to help migrate to new features where they make sense (and, I’ll be honest, sometimes when they don’t). It’s made making use of lambdas a lot easier.

For a while, IDEA was becoming slower and more bloated, but I’m pleased to see that, partly thanks to the work of developers from Facebook, the latest releases feel snappier and handle larger projects more efficiently. One thing I appreciate is how open Jetbrains were to receiving patches to their core product: it displays a level of respect for external contributors that I feel is important (of course, I would think that: I work on OSS for fun!)

There’s a nice wide range of plugins available for IDEA. I’ve hooked up the Buck plugin and made use of it. Without an extensions API, this plugin wouldn’t have been possible, but having them there is incredibly useful and makes the IDE even more capable.

Finally for the plus points of the IDE, I love that the IDE tracks new versions of Java relatively closely — it’s fun to see what new language features we’ll be able to use in the future!

The Cons:

Although it’s a fine product, there are some niggles to be had.

Most annoyingly, the built in code analysis doesn’t always warn that some Java classes won’t compile. The most recent example was where IDEA didn’t flag that some lambdas couldn’t be used since the choice of method to use was ambiguous. This may be because the Java language continues its slothful way forward, and the compiler improves with each release — certainly these same files compiled just fine with older Java releases.

When an error does happen, I’ve yet to find the magic setting to allow IDEA to keep going as far as possible. One of the features I like about Eclipse is that it’ll compile as much as it can, even if there are invalid source files. When doing TDD, this allows you to move just a little bit faster as unit tests can run and pass so long as they don’t touch faulty code. I dearly wish this same capability was present in IDEA!

On the Selenium project, we use Buck for our builds. The Buck plugin doesn’t (yet!) allow me to build and run tests within the IDE, yet Buck performs some steps that can’t be repeated by the IDE that are required for a successful build. IDEA offers the ability to run an Ant step before a build is run, and it would be extremely useful if this was generalised to “any shell command”. Most of the time, it’s fine, but it’s irksome to forget to run things!

On the whole, I love IntelliJ an awful lot. It’s a fast and capable IDE, and the company behind it supports OSS. What’s not to love?

Blog: Selenium 3.0: Out Now!

Thu, 13 Oct 2016 00:00:00 +0000

We are very pleased to announce the release of Selenium 3.0. If you’ve been waiting for a stable release since 2.53.1, now’s your chance to update. And if you do, here is what you’ll find:

As we’ve said before, for users of the WebDriver APIs this is a drop-in replacement. You’ll find that modern browsers, such as Chrome and Edge will continue to work just as before, and we’ve taken the opportunity to fix some bugs and improve stability. Selenium Grid users may require updates to their configuration as the json config file format has been updated, as have some of command line parameter options, but the upgrade should also be smooth.

The major change in Selenium 3.0 is we’re removing the original Selenium Core implementation and replacing it with one backed by WebDriver. This will affect all users of the Selenium RC APIs. For more information, please see the previous post.

A lot has changed in the 5 years between versions 2 and 3. When we shipped Selenium 2, the Selenium project was responsible for providing the driver for each browser. Now, we are happy to say that all the major browser vendors ship their own implementations (Apple, Google, Microsoft, and Mozilla). Because the browser vendors know their browsers better than anyone, their WebDriver implementations can be tightly coupled to the browser, leading to a better testing experience for you.

The other notable change has been that there is now a W3C specification for browser automation, based on the Open Source WebDriver. This has yet to reach “recommendation” status, but the people working on it (including members of the Selenium project!) are now focusing on finishing the text and writing the implementations.

Mozilla has been a front-runner in implementing the W3C WebDriver protocol. On the plus side, this has exposed problems with the spec as it has evolved, but it also means that Firefox support is hard to track as their engineering efforts have been forward looking, rather than on supporting the current wire protocol used by Selenium WebDriver. For now, the best advice we can offer is for you to try the latest release of geckodriver and Selenium together.

These are exciting times for browser automation! Selenium 3.0 is a major release and we’re looking forward to improving things further, as well as tracking the ongoing work of the W3C spec. Our goal is to keep the changes your tests need to deal with to an absolute minimum, to continue preserving the hard work that’s gone into writing your existing tests.

As a personal note, I’d like to say thank you to each of the many people that have worked so hard to make Selenium 3 possible. That’s not just the developers and contributors to the Open Source project (past and present), but also the engineers from Google, Microsoft, Mozilla, and Apple, and everyone involved with the W3C spec. I’d also like to say thank you to everyone who’s taken the time to report bugs, our users and our community. The project is great fun to work on and you’re the reason for that. A final thank you is due to the Software Freedom Conservancy, who have provided invaluable help with the logistics of running a large OSS project.

Happy hacking, everyone! May your tests run fast and true!

Blog: Selenium 3 is Coming

Tue, 04 Oct 2016 00:00:00 +0000

Selenium 3 is coming! As I write this, we think that “beta 4” will be the last beta before the official 3.0 release. I’m here to tell you about what’s changed, and what impact this will have on your testing.

TL;DR:

WebDriver users will just find bug fixes and a drop-in replacement for 2.x.
Selenium Grid users will also find bug fixes and a simple update.
The WebDriver APIs are now the only APIs actively supported by the Selenium project.
The Selenium RC APIs have been moved to a “legacy” package.
The original code powering Selenium RC has been replaced with something backed by WebDriver, which is also contained in the “legacy” package.
By a quirk of timing, Mozilla have made changes to Firefox that mean that from Firefox 48 you must use their geckodriver to use that browser, regardless of whether you’re using Selenium 2 or 3.

In more depth:

When we released Selenium 2.0 in 2011, we introduced the new WebDriver APIs, and encouraged everyone to start moving to them. If you’re using the WebDriver APIs, then Selenium 3.0 is a simple drop-in upgrade. We’ve not changed any of the public WebDriver APIs, and the code is essentially the same as the last 2.x release. If you’re using Selenium Grid, the same applies: in most cases, you can just drop in the new JAR (or update your maven dependency to 3.0.0), and you’re done.

If the update to Selenium 3 is such a non-event, why did we call this Selenium 3.0? To answer this question, I first need to provide some history, and tell you a little about how Selenium works under the hood. The very first version of Selenium was “just” a very complicated Javascript framework, running in the browser and interpreting the table-based tests you may be familiar with if you use Selenium IDE. We call this “Selenium Core”. This Javascript framework formed the basis of the original implementation of Selenium RC (the oldest set of Selenium APIs, where all the method and functions were on the “Selenium” interface, and which have been deprecated for some time now). Over time, the needs of modern web testing have grown ever more complicated and sophisticated, and Selenium Core is now less capable of meeting these needs than it was before.

With Selenium 3.0, we are deleting the original Selenium Core implementation. If you use the old RC interfaces, we provide an alternative implementation that’s backed by WebDriver. This is the same “webdriver-backed selenium” that has been available as part of Selenium 2 since its release. Because the underlying technology has changed from Selenium Core to WebDriver, you may find some places where your existing tests using RC run into issues. Our experience with migrating suites is that it’s normally a systemic issue that can be fixed with a minimal engineering effort (that is, the problem is normally isolated to a few places, and these can be rewritten to avoid problems)

We’re also removing the original Selenium RC APIs from the main downloads. If you’re a Java user, and need to use them to support existing tests, then you’ll need a dependency to “org.seleniumhq.selenium:selenium-leg-rc:3.0.0” (or later!). It’s strongly recommended that you do not do this unless you absolutely need to.
If you’re someone who runs tests exported from IDE in the table format, there is now a new test runner that the project has made available for you to use that can be downloaded from the project’s website. It takes the same arguments as the old runner, and we’ve done our best to ensure the output of tests remains the same too.

At the same time as the Selenium project is shipping Selenium 3.0, Mozilla are changing the internals of Firefox in a way that makes it more stable and secure, but which also makes the community provided Firefox Driver no longer work. As such, if you use Firefox for your testing, you’ll need to use the geckodriver, which is an executable similar to the chromedriver and the Microsoft WebDriver for Edge. You’ll need to start using geckodriver even if you’re using Selenium 2 — the change is in the browser, not Selenium. Please be aware that geckodriver is alpha software, based on the evolving W3C WebDriver standard: everyone’s working flat out to give you the best testing experience they can, but there are undoubtedly some bumps in the road when it comes to testing with Firefox.

This release marks the culmination of a lot of hard work by the Selenium committers and community. I’d like to thank everyone who has been part of this process, and the Selenium users around the world who have done so much to make the project as successful as it is.

Blog: Announcing Selenium 3.0-beta1

Fri, 29 Jul 2016 00:00:00 +0000

At SeleniumConf in 2013, we announced that a new major version of Selenium would be released “by Christmas”. Fortunately, we never said which Christmas, as it has taken us a while to make all the changes we wanted to make! We’re excited to announce the release of the first beta — Selenium 3.0.0-beta1.

We’d love you to try it out on your projects, and provide us with feedback on where the rough edges are before we ship the 3.0 itself! Please remember that this is a beta release, so your feedback is incredibly helpful and valuable in order to help us smooth any rough edges.

For the last six years we’ve been advising users to switch to the newer WebDriver APIs and to stop using the original RC APIs. With Selenium 3.0, the original implementation of RC has been removed, replaced by one that sits on top of WebDriver. For many users, this change will go completely unnoticed, as they’re no longer using the RC APIs. For those of you who still are, we’ve done our best to make the change as smooth as possible, but we welcome high quality bug reports to help us fix any problems that occur. Maven users will need to add a dependency on the new “leg-rc” package to access the old RC APIs.

There are some other changes that you might need to be aware of:

You’ll need to be running Java 8 to use the Java pieces of Selenium. This is the oldest version of Java officially supported by Oracle, so hopefully you’re using it already!
Support for Firefox is via Mozilla’s geckodriver.
Support for Safari is provided on macOS (Sierra or later) via Apple’s own safaridriver.
Support for Edge is provided by MS through their webdriver server.
Only versions 9 or above of IE are supported. Earlier versions may work, but are no longer supported as MS no longer supports them.

We’ll be posting more information about Selenium 3.0 to this blog soon, but until then if you’re interested in learning more then a recent webinar by Simon is a great place to start.

Blog: IntelliJ

Sun, 08 Feb 2015 00:00:00 +0000

Every year, Jetbrains are kind enough to donate an OSS license for IntelliJ to the Selenium project. As part of that process, they’ve asked that we review the product and (kudos to them!) have been clear that they hope we’re open and honest. So, I’ll be open and honest.

When I tell people that I’m a professional Java developer, people in some circles make sympathetic noises and (sometimes) jokingly refer to how painful my coding life must be. After all, there are several far trendier and hipper languages, from Ruby, various flavours of Javascript, Python, Haskell, and even other languages running on the JVM such as Scala and Clojure. I tend to agree that Java is a relatively unexciting language as it’s generally practiced — Java 8 contains a wealth of goodies that lots of people won’t be using for years since they’ve still got to support Java 6(!) apps. Where I disagree with the detractors is that using Java is something to feel sorry for a developer for: Java on its own isn’t much fun, Java and IntelliJ is one of my favourite programming experiences.

I’ve been using Java since the (very) late 90s, and have been using IntelliJ off-and-on since 2003 or so. In the intervening just-over-a-decade, what started as a tool that crossed the Rubicon of “being able to do refactoring” has matured. It has literally changed the way I write code: I now use the “Introduce Variable” refactoring to avoid needing to do initial assignments of values to variables as a matter of course. Indeed, with IntelliJ, I frequently stop thinking about the programming language and start thinking about the structure of the solution. Its refactorings make exploring large scale changes easy and entirely reliable, and once the restructurings are complete, I can jump to symbols with ease.

Code exploration is aided by the simple and quick ways IntelliJ can find usages, and it’s simple to find unused code as method declarations get highlighted in a different shade to used ones. The integrated debugger is sufficiently capable that, coupled with unit tests, it’s normally pretty easy to figure out why some odd behaviour is happening. And, speaking of unit tests, the UI is clear and (I find) intuitive and easy to use.

And those users of fancy-pants languages such as Clojure, Ruby, Python and Javascript (and PHP) can get plugins that extend IntelliJ’s capabilities and insight into those languages. Although it’s been a long time since I’ve had to deal with Spring and JEE, when I do IJ has my back, grokking the config files. The maven and gradle integration appears to work too, though Selenium uses CrazyFun and is migrating to Buck, so I’ve seldom any need to

It’s not all wonder and joy. On large, multi-module codebases, IntelliJ seems to spend too long building caches. Activity Monitor on the Mac suggests it’s doing this in a single threaded manner, which is wasteful on a multicored machine. Switching away from IJ, doing something on the command line involving source control and then switching back is a sure-fire way to make it rebuild the caches, making it unresponsive. Extending IntelliJ by writing plugins is a black art — the documentation is scattered and appears out of date, making getting started on writing one hard.

Overall, though, I love IntelliJ. On the Selenium project, it’s the IDE of choice, and I’ve been incredibly productive in it. Thank you, Jetbrains, for a wonderful tool.

Blog: Android and iOS Support

Tue, 24 Dec 2013 00:00:00 +0000

TL;DR: We’re retiring Selenium’s own AndroidDriver and iPhoneDriver in favour of any of Selendroid, iosdriver and Appium. If you’re using one of Selenium’s own mobile drivers, please evaluate one of these alternatives.

The longer version:

In 2007, Steve Jobs announced the iPhone and changed the mobile Web from a curiosity to something the mainstream wanted and used. Current trends suggest that mobile Web usage will surpass desktop usage in the not too distant future. Which is a long way of saying the mobile Web is going to be a big part of the future of your sites and that it’d be an extremely wise idea to test them on mobile devices.

The Selenium project responded to the rise of the mobile web by working to produce WebDriver implementations for both iOS and Android. The first lines of the iPhoneDriver (which also worked on the iPad) were added to the project early in 2009. The AndroidDriver was added in June 2010, and was primarily developed by engineers at Google. To this day you can download the official Android SDK and find “Google WebDriver” as one of the optional extras you can download.

After the initial work on the mobile drivers, something interesting happened. Experimental extensions and modifications to the drivers were made outside of the selenium project. The first one of these that I was involved with was “nativedriver“. This took the novel approach of allowing users to interact with the native UI of the phone, be it Android or iOS, using the familiar WebDriver APIs. The first time I saw it, I thought it was madness, but the engineers working on it soon convinced me that it made sense. And guess what? They were right.

Sadly, after proving the idea was viable and workable, the NativeDriver project ran out of steam, but it set the scene for three projects that have taken the idea and run with it to create remarkably capable pieces of mobile testing software: Selendroid, iosdriver and Appium. All three of these allow a tester familiar with the WebDriver APIs to test mobile apps on iOS and Android. Not only native ones, but also hybrid or pure web-based ones too. They’ve recently been joined by the Windows Phone WebDriver, which allows testing of mobile web apps on WinPhone 8.

All of these projects have something in common: they’re far more active, more capable and have pushed further than the equivalent code in the main selenium project. In fact, some of the members of the selenium team that contributed to both AndroidDriver and iPhoneDriver are now also working on those other projects. There’s work being done to maintain interoperability between the different drivers, allowing users to chose which framework is most appropriate for their needs without fear of their tests needing major rework.

This means that keeping the existing Android and iPhone drivers within the Selenium project isn’t helping our users. The alternatives are better, and keeping “official” drivers within the project muddies the water. Worse, the selenium developers are slow at making fixes to those drivers, which is incredibly frustrating for everyone involved. Because of this, the Selenium project has deleted the code for those drivers from its repository and we recommend you evaluate and use one of the alternatives.

Of course, the code will still live in our repo’s history, so if you’d like to build them yourself, then it’s still possible. The last version with the iPhoneDriver is ef9d578, and the last one with the Android source is 00a3c7d. We’ve uploaded a version of the AndroidDriver built from that revision to the downloads page to save you having to do so yourself.

These changes do not mean that we don’t support mobile as a project. It just means that we support the best implementations of mobile WebDriver, and those aren’t written as part of the Selenium project.

Blog: Mobile WebDriver

Wed, 28 Aug 2013 00:00:00 +0000

Although the WebDriver APIs started life as just a mechanism for automating web browsers, over the past few years it has been extended to also work on mobile devices. Projects such as Appium, iosdriver, and Selendroid have all shown that this approach works, and works well. On the Web, if you start using Selenium WebDriver with one browser (Firefox, for example), it’s easy to switch out the browser for another one (such as Internet Explorer or Chrome). It’d be nice to have a similar option for mobile, switching from one automation framework for Android to another.

As part of the Selenium 3 work, we have started working on a test suite to help ensure this level of interop between appium and iosdriver, and appium and selendroid. To kick start the process, the primary authors of each of those tools, as well as others including David Burns representing the Marionette project (Mozilla’s implementation of WebDriver for Firefox and Firefox OS) and Simon Stewart, the lead of the Selenium project, have spent the past two days locked in a small room in Mozilla HQ, London. They’ve taken this time to work out the areas where each of their projects didn’t align and agreed on a way to ensure a level of interoperability. There was only a minimal quantity of blood and tears, but plenty of hard work.

The agenda for the past two days can be found here, and the minutes are also available.

As we speak, work has started on a shared test suite, hosted in a repo in the selenium project’s Google Code page. Please, feel free to come along and join in!

Blog: The Road to Selenium 3

Wed, 28 Aug 2013 00:00:00 +0000

Selenium 2 was released in July 2011. It’s now two years old, and what a couple of years it’s been! The WebDriver APIs, which were the major addition in Selenium 2, are now the basis for a W3C standard, and there are implementations written and supported by Google, Mozilla and Opera. There have been 34 releases, with official support for Java, C#, Python, Ruby and Javascript, and the community has stepped in to provide bindings for Perl, PHP and others. There have been 57 different people authoring changes in the code base, and countless more participating in the online forums, offering help and advice.

While all this has been happening, the world has moved on, and now it’s time for the Selenium project to look to the future. It’s with great pleasure that I can now say that we’re working towards Selenium 3.

We aim for Selenium 3 to be “a tool for user-focused automation of mobile and web apps”.

What does this mean? For mobile users, the Selenium project will be hosting a suite of tests to facilitate interoperability between the many different projects available that are extending the WebDriver API to also cope with mobile. Developers from projects such as Appium, ios-driver and selendroid will be working on the suite of tests to enable this.

We’ll also be working on making the technology behind Selenium as stable and capable as possible. For this reason, Selenium 3 will see the removal of the original Selenium Core implementations, and consequently we’ll be deprecating the RC APIs too. The old versions will still be available as a separate download, but active development will cease, except for very urgent fixes. We will still be providing an implementation of the RC APIs backed by WebDriver, so you can continue running your existing tests, but now would be a great time to make the move to using the WebDriver APIs directly.

For those of you exporting your tests from IDE and running the HTML suites, we’ll provide an alternative runner that allows you to continue running those tests too, though it’ll be backed by the same “WebDriver-backed” RC implementation as offered by the main download. Again, the original implementation will be available as a download, but it will no longer be actively developed once we release 3.0.

Our current plan is to start shipping 3.0 by Christmas this year: it’s going to be a lot of fun!

Blog: A Smattering of Selenium #157

Sun, 18 Aug 2013 00:00:00 +0000

Trying to find every excuse not to cut the grass … including apparently closing some browser tabs.

Interoperability – Standardized Test Information Interchange has me so full of ‘meh’ as to be hilarious. Commercially driven standards rarely are and/or I am just too much of an open source person to accept this model for standards development
Licensing in a Post Copyright World – important
How to Make Async Requests in PHP is php specific in its solution, but has some interesting bits about socket establishment that applies to other ones as well
Adding Comments to JSON feels like a hack. Buts a clever hack.
Maven Release Plugin: The Final Nail in the Coffin takes great joy in removing part of the maven environment from their workflow. And really, who doesn’t?
Open Sourcing a Python Project the Right Way is nice … though of course, as with everything else these days, it has some Github specific isms. You can do it the right way with hg and bitbucket of course… and that is disclaimed in the article
Headless Watir using both HTTPUnit and PhantomJS
Implementing HTTP Status Codes in WebDriver, Part 2: Achievement Unlocked – umm, part 2?
PhantomJS + Plugins + AWS + BrowserMob Proxy – proxy all the things! Including headless things.
Mastering the Craft is a good reminder, but also, eBay has its own customized version of eclipse? Guessing this is one of those ‘at scale’ solutions

Blog: A Smattering of Selenium #156

Mon, 12 Aug 2013 00:00:00 +0000

Brain fried from PyCon Canada 2013 and ‘some’ browser tab is misbehaving which means its time to start closing some of these.

Patchwork seems like an awesome idea, but at the same time, I’ve had to work in heavily monkey-patched RoR apps before…
Evolving syntax is PHP specific in its examples, but the ideas transfer
Roslyn + Selenium: Scripty C# Powering Browser Automation – some C# voodoo?
It’s like 10000 knives when all you need is a Spoon – or specifically, this particular spoon which is yet-another-android-automation-tool. See comments for a bit of discussion re Appium which seems to be the currently best marketed solution in this space
Planet generator has absolutely nothing to do with automation, but is just cool
TestSpicer could be cool if it is massively flushed out
Compatibility changes in IE11 Preview is going to break things I fear, for instance the readyState stuff?
PyCon Canada 2013 decks are now up
Implementing WebDriver HTTP Status Codes, Part 1: Challenge Accepted – is interesting in that it uses Fiddler
Links are not buttons. Neither are DIVs and SPANs – this, a million times.

Blog: The World’s Best Selenium Meetup

Fri, 09 Aug 2013 00:00:00 +0000

Note from Adam: This is a guest post from Dave Haeffner who, along with David Burns hatched this idea at SeConf2013.

Selenium Meetups are great, but…

Have you ever wanted to attend a Selenium Meetup but there’s not one near you? Or maybe there is but something’s come up and you can’t make it out that night? Or maybe the meetup near you struggles to get good speakers and have a consistent schedule? [Note from Adam; like, say, the Toronto one…]

We can do better

Well, what if there were a way to attend a meetup regardless of location?

And what if each meetup you attended was lined with core maintainers of the Selenium project?

And if you missed it, what if the whole thing was recorded and available for you to review at your leisure?

Well, now you can.

The World’s Best Selenium Meetup

Introducing Selenium Hangout — the world’s best and most accessible Selenium meetup. An entirely online meetup that leverages Google Hangouts and live streaming to YouTube. All meetups will be recorded and posted online afterwards.

Each meetup will contain a small panel of people from the Selenium Community (e.g. core committers, automation practitioners, etc.) and they will discuss various topics (TBD).

How to attend

Simply follow the SeleniumHangout Twitter account to find out more.

Blog: A Smattering of Selenium #155

Sun, 28 Jul 2013 00:00:00 +0000

A ‘should be scripting, but brain stuck in neutral so closing some tabs’ edition of the Smattering.

The slippery slope isn’t automation related, but if your employer does these things I’d suggest logging a bug and then finding an ethical job
Why Package Signing is not the Holy Grail – crypto / security is hard. Also, I have a signed package for you to install…
PHP and Async requests with file based sessions could be a way to speed up a PHP site. Which in turn reduces the amount of time your scripts take to run
Canadipsum, eh? just because. (eh)
Using CodedUI testautomation without UIMap files brings Page Objects to CodedUI
Continuous Delivery Workshop With Neal Ford (@Neal4D) – a Retrospective – yup, the hard part is not the technical bit, but the people parts
librarian-puppet says You can all stop using git submodules now which is good enough for me
Highlighting the element before any clicks: A foray into the AbstractEventListener — the event listener stuff is something I need to sort out.
phpci is built specifically for php apps, and doesn’t pretend to have the features something like jenkins does
Beware subclassing Ruby core classes – there are likely parallels in other languages as well.

Blog: A Smattering of Selenium #154

Tue, 23 Jul 2013 00:00:00 +0000

Apparently today’s ‘wait for an email’ task is to whittle down the smattering queue some more.

I won’t even pretend that FOAAS has to do with automation, but makes me laugh. Also, depending on how crappy your place of work is, it might not be SFW
PHP RFC: Importing namespaced functions is interesting if you are writing your scripts in a Functional manner. In PHP. In a future where it gets accepted and implemented.
Measuring Web Page Load Times using JMeter — and read the response articles too for clarification / elaboration
I kinda like that Se suites are making their way into large projects such as Moodle’s functional-test-suite repo. But at the same time it worries me when it hasn’t had a commit in 10 months. Suites should likely change even more than the app code it exercises
jasmine tactics screencast — on the long list of tools I should learn
Introducing the Mogotest Jenkins Plugin – hurray for more pipeline integration points
The DOM isn’t slow, you are. — set the phasers on snark, and then read it anyways.
Cross-Browser, Event-based, Element Resize Detection – edges are sharp.
There is No ROI in Social Media Marketing – read this, and now read it again swapping in Functional Automation everywhere
Now Available: Pocket Guide to Colour Accessibility could, in theory, be translated into a set of ‘rules’ to validate pages against since we can the colour of elements and their computed css values.

Blog: A Smattering of Selenium #153

Mon, 22 Jul 2013 00:00:00 +0000

A Sunday Smattering? Sure!

Solution to the Selenium with Firefox 22 Issues and How to Report Issues – Open Source is hard. Supporting Open Source’s infrastructure is harder — by a large margin
frequests – asyncronous HTTP Requests; not sure where I would use this, but…
why I don’t touch crypo – again, don’t. touch. crypto
Five reasons why you should quote attribute values in HTML5 – for the record, you should do this in HTML 4 as well.
All the ‘Write The Docs session videos — a conference I couldn’t afford to attend, and likely don’t have the time to watch the videos now
Automated Testing of HTML5 Canvas Applications with Selenium WebDriver – more and more important…
Solving window.onbeforeunload nasty prompts
pytest-poo for when your tests are, erm, crappy
Tada! Here is SlimerJS! – like PhantomJS but for Gecko. I think.
Did I select the right element? is a neat trick for highlighting things — even if the escaping of the code didn’t seem to survive formatting

Blog: A Smattering of Selenium #152

Thu, 11 Jul 2013 00:00:00 +0000

40-ish minutes until midnight eastern so that counts as two days in a row, right? Right?

Improving jenkins execution times by common sense — common sense. sadly lacking most days.
How to make test automation more effective? is useful up until the pitch at the end. So read until you get to that.
Data Structures for PHP Devs: Trees – non-trivial data structures are non-trivial
Writing clean WebDriver test suites for “duplicate” functionality by parameterizing on page objects – I especially like the usage of ‘might’ at the top
dalek-internal-webdriver – what’s a day without a JS webdriver implementation?
Antialiasing 101 – I kinda think that automators should just spend a day reading this site rather than reddit
RSpec 2.14 is released!
HTTP/2 Status Update – Ugh.
PHP 5.5: Generators – You know, with yesterday’s phpenv I’m almost tempted to make some of my stuff PHP 5.5…
Program Like a Machinist – hurray for understanding the motorcycle example!

Blog: A Smattering of Selenium #151

Wed, 10 Jul 2013 00:00:00 +0000

Almost a month after the last one. Though it did nice to have it at 150 when people go to the blog … but a greater number is nicer.

So I was trying to find Requests for PHP whilst talking to the grumpy programmer and he pointed me out to Guzzle which looks equally cool
Can you optimize list(genexp) is one of those geeky language internals things that could be handy to have in your back pocket
Slightly Snarky GWT Debug ID FAQ – c’mon, when have you seen a more blatantly ‘put this in the smattering’ title than this?
phpenv could be useful. And could be I mean ‘holy crap this is useful’ — but then again, I do actually need 3 different versions of PHP locally. YMMV
Pain killing the pingponger’s decease is by their own admission not stable, but is a nice temporary solution. And illustrates why you should learn your tools — if they didn’t know about custom annotations and their runners in JUnit they would have missed this.
Yet another JS testing framework has grown a webdriver tentacle – karma-webdriver-launcher
I barely understand a word of Method Combinators in CoffeeScript which is often a sign I should include something
How are JavaScript files being served and how many are there? is interesting … even if I don’t understand what/where he has put all this HAR information so one could reproduce this on their one data
Statically Recompiling NES Games into Native Executables with LLVM and Go – $entity help us if we ever need to do this level of ridiculousness to drive browsers, but holy wow its cool.
Remember I said I should just auto-include all of Raymond Hettinger’s SO answers? Well, here’s another one – Python importing class attributes into method local namespace

Blog: A Smattering of Selenium #150

Fri, 14 Jun 2013 00:00:00 +0000

Yup, this smattering has very little to do with Selenium, but… 150!

Referencing DOM from JS: there must be a DRYer, safer way is a nice ‘here is where I started, and here is how I ended up where I am’ post which can be stolen into other languages / frameworks other than in Backbone
Hash lookup in Ruby, why is it so fast? is not something I was wondering, but now I know why.
Nobody understands the GIL – in any language.
Resource Locator Discussion – namespace all the things!
How to Survive the Coming Test Automation Zombie Apocalypse is abso-freaking-lutely awesome
Blackhole proxy to block all external calls is a snippet that came out of SeConf this week
Filter a list into two parts. Ouch. My brain just broke. (But generators do that to me.)
What you need to know about dates and times in computing could be useful. If one kindles.
SSL Helpers is a couple python scripts for manipulating certificates
storyautomation seems to have a number of decent posts. Of course, they are around RC so I was hesitant to link to it, but it looks like the ideas could transpose up to WebDriver

Blog: A Smattering of Selenium #149

Wed, 05 Jun 2013 00:00:00 +0000

Too. Many. Tabs.

Internationalization and Localization Testing — yup, I agree.
5 HTML5 Features you need to know – ‘download attribute’ and ‘datalist element’ might be a pain for us automators. Or at least cause a couple hours annoyance until we figure out the pattern.
Death to sleeps! Raise of Conditions! – expected conditions is likely the next thing to get more marketing this year
line_profiler and kernprof – profiling is black magic voodoo
Naught – ‘Naught is a toolkit for building Null Objects in Ruby.’
Replacing a substring of a string with Python – Raymond’s answers always simultaneously break my break and blow my mind.
When splitting an empty string in Python, why does split() return an empty list while split(‘\n’) returns [”]? – see what I mean?
So you want to build a framework – mine, but important. (I think.)
Locks, Actors, And STM In Pictures – ya! pictures!
Packaging a ruby script as an Windows exe using OCRA looks like something useful

Blog: A Smattering of Selenium #148

Mon, 13 May 2013 00:00:00 +0000

Gotta start this up again…

The Evil Tester Guide To HTTP Proxies appears to be more for using proxies for manual testing, but you should be running your automation through one as well so it helps to understand the magic that takes place.
New BrowserMob Proxy release. Bindings should all be updated for the newly exposed methods in a couple days.
5 Things You Should Stop Doing With jQuery – Not sure whats better, the content, or the Saved By The Bell theme
testtools is the latest hotness in the world of Python runners?
Boris looks pretty useful for the PHP folks
Google’s Scaled Trunk Based Development – even if you are not Google, you should be doing this. Or as much as you can (again, you are likely not Google)
Reliably Testing Asynchronous UI W/ RSpec and Capybara isn’t new, but the wait_for_dom thing is new [to me]
In defense of – canvas worries me
One Does Not Simply Set Profile for Remote Chrome is Watir, but links to the pure WebDriver in SO article. I don’t think any of the other bindings deliver chrome profiles over the wire…
The Moodle Functional Test Automation Harness – always fun to peek into other’s suites

Blog: A Smattering of Selenium #147

Thu, 14 Mar 2013 00:00:00 +0000

My. Get. Productive. I know! I’ll push out a smattering. Oh. …

Python for Ruby Programmers is a pretty good deck, with the requisite snark at the end that you can safely ignore.
Me @ Selenium Camp 2013 is Ivan’s mini-experience-report from SeCamp and has his slides on GhostDriver
Using pip in production? pip install : Lightspeed and Bulletproof is a useful trick which I know I’ve done variants of with java and ruby in the past
SeConf speakers are up — and the list looks really good
Interfaces or Abstract Classes? is marketing fodder, but its the best kind of fodder since its actually useful. For those of us still working through PHP.
I forgot about this semantic war in the whole three weeks since it happened…
Android UI Design Pattern in practice is not only useful, but I like the format…
Continuous Deployment: The Dirty Details – slide 18, 36, 42, 83, 102 are the killer slides. 102 is the killer-est slide and is where I would enter a semantic debate with the fine folks at Etsy over whether they are doing Continuous Deployment or Continuous Delivery
Could CSS3 be making sites that are not testable? – New standards making the life of automators more incredibly hard? Never!
Python – verify a PNG file and get image dimensions

Blog: A Smattering of Selenium #146

Mon, 11 Mar 2013 00:00:00 +0000

Happy ‘productivity destructive week’ — otherwise known as March break.

How to Accept Self-Signed SSL Certificates in Selenium 2 — or you could use ‘real’ certificates that are trusted by the browser by default. If you are using self-signed certificates to ‘save money’ and you spend 3 hours making it work, you are not saving money anymore
JockeyJS seems like it could be useful
Dear every-js-widget-library-author, You can’t create a button
If you are using PHP, then The Grumpy Programmer’s PHPUnit Cookbook should be added to your reading pile. Thankfully he doesn’t touch on the built-in WebDriver stuff but the ToC still looks relevant to what we do
WordPress Performance Optimization is just cool — and could provide tricks for your non-WordPress apps too
Single-Session Development is something I don’t do — but can appreciate the geek-ness of this
JUnit’s evolving structure shows what the, erm, evolving structure of JUnit and has the killer line of ‘Programmers should be forced to wear their systems’ package-structures on their tee-shirts.’
Basic Authentication With the BrowserMob Proxy, wow, that’s an annoying edge-case
Breaking Down Amazon’s Mega Dropdown – ugh, because mouse events weren’t hard enough without menus tracking and rendering based on its position
If you are intro RSpec, then RSpec Next Steps is going to be for you. Even if it does use a horrid html-based deck format (use the left/right arrow keys to navigate)

Blog: A Smattering of Selenium #145

Mon, 04 Mar 2013 00:00:00 +0000

Alice Finch builds massive LEGO Hogwarts from 400,000 bricks starts out at awesome and goes somewhere further down the scale when you get to the photo that shows scale.

Models of Automation — really, who reading this hasn’t had the conversation described in there in one of its variants
Stop Moving So I Can Click You Dammit! – illustrates the only acceptable place for Thread.sleep()
Using Realistic Data in Unit Testing and AngelaSmith: Creating Test Data is a two-for for the C# crowd — though the ideas resonate with everyone else
How to handle common components with Page Object Model? — I tend to use Inheritance, though am experimenting with Composition. The right solution is likely ‘both’
Dear Nic, Should we log directly? illustrates the good and bad of unix pipes
How foreach actually works was found via a snarky tweet, but is great
Introducing the HTML5 Hard Disk Filler&tm; API is hilarious. And the next salvo in the WebKit vs mono-culture battle
HTML’s New Template Tag – Standardizing Client-Side Templating — look! More HTML5 madness! And no automation suggestions / gotchas. But HTML5 Rocks is a great site anyways
Why your web app should be responsive — I’m coming to dislike the term ‘responsive’, though agree with the sentiment. Now, how does your WebDriver [or Watir] scripts change in order to handle this?
Nyan Cat RSpec Formatter is outstandlingly silly. And should be applied to all your RSpec runners. Immediately.