Selenium is the most widely used software for automating UI testing, and while some maintain it is flaky and not facile at managing dependencies, the project has found its way into many development shops.

Last month saw the release of Selenium 4, which Simon Stewart, former lead of the open-source Selenium project, said introduced “a lot” of new features and bug fixes, both from the point of view of a tester using Selenium to automate a browser, and from an improved Selenium Grid.

For testers using Selenium, new features include “relative locators,” which allow the tester to describe where an element is on a page using human language, such as “above this element” or “to the right of that element, explained Stewart, who stepped down from his role on Oct. 27. The release adds support for handling authentication, intercepting and stubbing out network traffic, and capturing JavaScript errors.

Further, there is new support for Chromium-based Edge out of the box. “When we released the last version of Selenium 3, that browser didn’t even exist,” Stewart told SD Times. He added that the project team cleaned up the internals of Selenium itself, allowing work on the codebase to proceed at speed. “It’s not often a project has a chance to pay down some technical debt,” Stewart said.

Stewart described the update to Selenium Grid as “a ground-up rewrite of what we had in Selenium 3.” This includes integrated support for using Docker containers, and adds a “fully distributed” mode, designed to ease the deployment of large Grids into environments such as Kubernetes, he said, to go along with support for the original “standalone” and “hub and node” configurations.

Grid has a new UI sitting atop a GraphQL back end, and offers live views of tests running on the Grid. This, Stewart explained, “is a remarkably useful thing to be able to do. Of course, modern sysadmins don’t just rely on an app’s UI to determine if everything is working as it should, so we’ve made the Grid ‘observable’ using … OpenTelemetrty APIs. This allows you to use tools such as Jaeger or Honeycomb to dig into the internals of each and every request.”

Stewart has heard critics who say Selenium requires special expertise to run, that it’s difficult to scale and needs a lot of maintenance, and responded by saying, “I’d suggest that the Selenium Grid is no more complex or complicated than any distributed system you may wish to deploy to Kubernetes, and the support those applications need is the support the Grid will need. Asking a QA team to deploy and manage this kind of application is probably asking too much of them, just as asking them to manage your production apps in Kubernetes would be.” He went on to say that “the Selenium Grid is like any distributed system you may want to run at your company: when things are working well, it’s fine, but debugging issues can take time and specialist skills.”

He noted that the project has tried to lower this kind of burden through support for Observability, which helps teams keep up with the rapid release schedules of modern browsers. “That’s why ‘Selenium-as-a-Service’ providers, such as SauceLabs and BrowserStack, as so popular. Even projects that compete with the Selenium Grid try and steer people to centralized systems that they maintain for you.”

Observability also makes diagnosing issues simpler, Stewart said. Each of the components within the Grid has a clear REST-based API that can be implemented in whichever way a user prefers. In-memory implementations of these are part of the main Selenium 4 distribution, and that are database or Redis-backed implementations of the stateful parts of the system, which had not been done previously.

While Selenium offers automated browser testing, Stewart said, “I don’t think we’ll ever be able to remove people from the mix, no matter which test library we use — particularly if the test is to be written before the software has been developed,” such as in teams practicing Test-Driven Development.

Stewart explained: “I’ve seen people try to automate generating Page Objects, and these usually end up mapping input elements to properties of the object, so rather than ‘loginPage.loginAs(“admin”, “admin”)’ you end up with ‘loginPage.setUsername(“admin”); loginPage.setPassword(“admin”)’. That is, expressiveness and clarity have been sacrificed to the convenience of generating the Page Object, and since the real cost of a test is in understanding and maintaining it, I think this is a false economy.

“On the other hand,” he continued, “computers are really good at generating and running exhaustive examples and inputs. I’ve seen some very creative uses of Selenium which spider a site and attempt to spam any forms that they come across, or that ensure that the “tab index” (the order in which form elements are focused as people hit the “tab” key) makes sense. For those kinds of tests, I’d much rather rely on an autonomous test than one a human wrote.”

To get started with Selenium itself, there are numerous resources, such as those offered by the Test Automation University. The Selenium site has documentation in multiple languages for using Selenium. More immediate help can be found in the project’s Slack channel, where the core developers are often online to answer questions and offer advice.