Official Selenium Blog

December 24, 2013

Android and iOS Support

Filed under: Technical — shs96c @ 4:18 pm UTC

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.

August 28, 2013

Mobile WebDriver

Filed under: Technical — shs96c @ 1:50 pm UTC

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!

January 22, 2013

A Plan to Drop Firefox 3.x Support

Filed under: Technical — shs96c @ 4:52 pm UTC
The support policy of the selenium project for Firefox browsers is to support the current and previous stables releases, as well as the current and previous ESR releases. At the time of writing, that means the supported versions are “10” and “17” (ESR) and “17” and “18” (stable channel). In addition to this, we are currently supporting Firefox 3.x too.
This is an official announcement that we are planning to end support for Firefox 3.x in the near future in RC, WebDriver and Core/IDE, and this is your chance to be involved in that decision. Unless there is a strong reason to do otherwise, I shall shortly be announcing a timeline for the end of the support of 3.x
Once support for Firefox 3.x is removed, the earliest supported Firefox version will be the ESR-1 release (currently Firefox 10).
Firefox 3.x is no longer actively supported by Mozilla, and this has been the case since April 24, 2012. Since this time, 3.x has dropped to under 1% of global Web traffic (0.62% at the time of writing according to StatCounter) Continued focus on supporting an effectively dead browser prevents the selenium team from using features in the newer releases for little benefit to you.
Continued support of Firefox 3.x by the selenium project gives the impression that that particular version is still a valid option used by the population of the Web. This is simply not the case, and it may mean that testers efforts are being spent fixing problems that almost no users will ever see.
What you can do:
If you agree that this is the right choice, then you do not need to do anything. If you disagree strongly and have the numbers to back up your position, particularly if you can help work on Firefox 3.x support, then please reply to the selenium-user google group.
On a personal note, I know that a lot of you may well have firefox 3.x support in your test plans and will be distressed by this plan. Please take the time to look at actual usage logs from your sites and applications to verify that continued support is worth your time and energy before responding. I’d really appreciate that.

January 14, 2013

Source Control

Filed under: Technical — shs96c @ 2:22 pm UTC

This short technical note is to announce that the Selenium project is now using git on Google Code in place of subversion.

The move has been a long time in the making, and it’s largely thanks to the efforts of Kristian Rosenvold that we’ve been able to do the migration and retain the project history. The project owes him a huge thank you! We’re in the process of migrating the last bits and pieces (none of which are user facing), so there may be some last minute turbulence as we settle everything down.

Although the canonical source will be on Google Code, we’re working on setting up a github mirror. We’ll announce the location of that once it’s set up.

February 24, 2012

Support for Ancient Browsers

Filed under: Technical — shs96c @ 11:39 am UTC

The first code checked into the Selenium project’s public repository was in November, 2004. We’re now in 2012. In the intervening years there have been many browsers released. The last browser we officially stopped supporting was Firefox 2.0, and it’s time to review the list of browsers again.

We periodically review the list of supported browsers as the more changes there are between the oldest version of a browser that we support and the most recent, the harder it is for us to add new features and maintain those that already exist. Balanced against the cost of maintaining the selenium code base itself are your tests; we know that your users might not be updating their browsers to the latest and greatest, and we know that you’ve still got to prove your app works on all the browsers that are important to you. That’s why what’s below is just our plan, and we’re talking about it now to let you have your say.

Looking at the market share of the browsers out there helps us make an informed choice about what it makes sense to support. This will most likely mean:

Firefox: the Firefox market appears to be split between those on 3.6 and those on the new rapid release schedule. Given this, we are thinking of officially supporting Firefox 3.6, and the last, latest and next release of Firefox (currently Firefox 9-11) as well as any ESR releases. The market share for Firefox versions 3.0 and 3.5 is tiny, and the effort to keep them working with selenium is disproportionately high.

Internet Explorer: Despite Microsoft’s efforts, IE 6 is still a popular browser, particularly in the workplace. We will continue to support IE versions 6 and up.

Safari: Safari 3 is now ancient and has been superseded by newer releases. We plan on only supporting Safari 4 and 5.

iOS: We’ll continue to target the most recent iOS release.

Android: Due to some technical limitations in previous Android releases, we are targeting Ice Cream Sandwich and onwards. We will continue to make available the testing framework for Froyo, but will not be making any changes to it.

These are only our plans. If you really need those browsers, and (better!) can help us maintain support for them, then please let us know.

You’ll notice that Opera and Chrome are not listed above. Since Opera and Google now maintain the drivers for those browsers, they are best placed to decide which are the supported versions, but in summary, Google support the major Chrome release channels (stable, beta, dev and canary) and Opera suggest using Opera 11.6+.

February 8, 2012

A Note About the Cybervillains SSL Certificate

Filed under: Technical — shs96c @ 9:10 pm UTC

If you’re using Selenium RC to test websites hosted on a secure site (accessed using a URL starting with HTTPS), we strongly recommend that you upgrade to Selenium 2.19. This is because the Cybervillains certificate in previous versions will expire soon, and has been replaced in 2.19 with an updated one.

Our thanks to Patrick Lightbody, Ivan De Marino and Mark Watson and Neustar for taking providing the new certificate and the patch!

January 5, 2012

Selenium 2.16 Released: Welcome to 2012!

Filed under: Releases,Technical — shs96c @ 11:36 am UTC

It’s been a while since we last blogged about a Selenium release. Since the release of 2.0, we’ve been attempting to give you a fresh and shiny Selenium release every week (though, in reality, we’re managing to get you one every 10 days on average). This allows you to pick the version that’s most suitable for you and your teams, but provides a route for quick feedback on how we’re doing. I think we’ve now ironed out a lot of the initial problems and bumps we ran into, so we are extremely proud to announce the release of Selenium 2.16.

If you’re unsure about what’s been happening since the last time we announced a release here, the best place to look is our changelog. The most notable feature in 2.16 is better support for Firefox 9, but if it’s been a while since you’ve last updated, we’ve been beavering away on bug fixes and making existing features work as flawlessly as possible. Now’s a great time to update!

One of the key tools we use for assessing whether it’s okay to push a release is our continuous build. This watches for each and every change made to the project’s source code, and runs an increasingly vast suite of tests to verify that nothing has broken. Our friends at SauceLabs have been extremely generous in providing support for this, and have worked closely with us to make the build as stable and quick as possible. Special kudos and thanks to them!

February 15, 2011

Selenium 2.0b2 Released

Filed under: Releases,Technical — shs96c @ 2:06 am UTC

We’ve just released Selenium 2.0b2. If you’re the impatient sort who loves to have the latest and greatest, head over to the download site and get it while it’s hot. If you’re a Python user, then all you need to do is a simple “pip install -U selenium”. Ruby users can, as ever, simply run “gem install selenium-webdriver”. Maven users need to wait just a little bit longer: we’re going to be checking the release in ASAP.

Between beta 1 and beta 2, we held a week-long Bug Bash, during which we closed a significant number of bugs. From a user’s perspective, other highlights include:

  • A more stable, capable iPhone driver.
  • Updated Android driver.
  • Improved python bindings for Selenium WebDriver. The namespace is now “selenium.webdriver”
  • Added “Selenium.getCssCount” to mirror “Selenium.getXpathCount”
  • WebElement.getText()” performs more consistently across different browsers.
  • Mono users can use the .Net bindings
  • Continued to improve the WebDriverBackedSelenium. If you’re looking to migrate from Selenium 1 to Selenium 2, and want to take your time, this is a useful stepping stone.
  • Reworked the Advanced User Interactions APIs. The big change is that the WebDriver APIs no longer rely on classes from the AWT.
  • .Net users now have more support classes, to make writing tests less tiresome.
  • The remote webdriver makes better use of sockets, which improves stability and scalability on Windows.
  • Started to add support for driving multiple IE instances. This is considered experimental, but we’d love to hear it’s working for you!

If you’re interested in the guts of Selenium 2 and how it worked, then you might find these interesting:

  • Continued reworking the IE and iPhone drivers to use the Automation Atoms.
  • Reworked the structure of the source tree to be more language focused.
  • We have the skeleton of a webdriver-backed selenium for Python.

As you can see, this is a big release. Beta 3 should be out a lot more quickly, and will be focusing on improving support for IE 9 and Firefox 4. Over the course of the 2.0b3 development, we shall also be removing as many deprecated methods as possible, so be sure to remove deprecation warnings from your builds when using 2.0b2!

September 5, 2010

Going Atomic: How

Filed under: Technical — shs96c @ 10:47 pm UTC

This is the second of my technical posts. Again, if you’re interested in the internal workings of Selenium 2, then please skip straight to something else. If you’re interested in how and why we made some of the technical decisions on the project, keep reading….

We left our intrepid heroes in a tight spot: they’d decided to write a shared library of code, to be used by the various webdriver implementations and selenium core, but the requirements for doing this seemed to be at odds with it actually happening.

Fortunately, at about the same time we started down this path, Google Open Sourced the Closure compiler. This is a Javascript compiler that takes as input a set of Javascript files, and which outputs Javascript. It can be configured to either pass the code through untouched into a single file, or it can compile a script aggressively, removing unused code-paths and minifying the output as much as possible. The Closure compiler is used on a lot of Google products, so we know that it’s reliable and consistent.

In order to get the best out of the Closure compiler, we’re writing the atoms using the Closure library. This isn’t as well known as some of the other JS libraries out there, but it’s solid, well tested and is being actively developed. It also features an easy-to-use extension of JsUnit, which makes writing tests a far simpler task than might otherwise be the case, and it has an easy to use mechanism for modularizing code.

So, given that we could compile a single Javascript function (and it’s dependencies) into a minified fragment of JS, we were all set, right? Not quite.

The problem is that the atoms are being extracted from two frameworks that have a different way of viewing the world. As an example, Selenium 1’s “getAttribute” method only returns the value of a particular attribute, whereas WebDriver’s “getAttribute” method will return the value of either a property or an attribute (because sometimes it’s hard to remember whether something is an attribute or a property of an element)

As with all problems in computer science, an extra level of indirection is used to solve this issue.

We’re busy implementing the expected behaviour of both WebDriver’s and Selenium’s API on top of the atoms.

There is, of course, the obvious question about how we get this carefully compressed JS into a driver. One option would be to include the raw Javascript as files in each language binding, and pull them in as required. That’s possible, but it would make each language binding bloated, and would introduce a lot of duplication. The alternative is to push the atoms as far into the driver as possible, and this is what we do. As part of the build process for webdriver, we take the compressed JS and convert it into a form that can be consumed by a particular driver. For example, for the IE driver, we convert them into constants in a C header file. These constants can then be referred to by the driver and converted back into a script than be executed via the same mechanism that is used by “executeScript”.

What do we gain from this seemingly baroque approach? Other than the ability to share the same code between drivers? Many things. The cost of maintenance drops dramatically as we can fix a bug in one place and have that fix be picked up by every driver. Because we’re working in pure JS and just querying the DOM, we can run the unit tests in a browser whilst we’re developing the code. This leads to a very tight feedback cycle. It also makes it easier for developers not familiar with the code to take a look at how we do things, and send us patches (always appreciated!) Finally, we can ensure a consistency of result.

Right, any questions?

August 16, 2010

Going Atomic: Why?

Filed under: Technical — shs96c @ 7:37 pm UTC

This is the first in a series of technical posts by me about the internals of Selenium WebDriver. If you’re not interested in technical nitty-gritty, then feel free to step away now.

Still here? Excellent.

Let’s take a step back to just before the Selenium and WebDriver projects merged. There were, very obviously, two separate codebases. Looking closer and with a slightly different perspective, there were more than this. We used the test suites for webdriver to define the behaviour for multiple, largely independent, driver codebases. The IE driver was written in C, the HtmlUnit driver in Java and the Firefox driver is largely Javascript, and so on.

This means that there was a lot of “congruent code”: code that performed the same function but was implemented in a different way. The natural result of this was there was the possibility for behaviour to diverge between drivers. Worse, it meant that when a bug was found, we had to check it in every browser, and it wasn’t certain that an individual could actually fix the code. After all, not everyone is comfortable writing in all the languages we use on the project, or is au fait with all the technologies. For an Open Source project like Selenium, this is a major problem: we rely on a relatively small core of key developers backed up with a far larger team of individuals submitting small changes and fixes. Anything that makes it harder for us to function effectively as a development community is a Bad Thing.

So, we wanted a way off the island; a mechanism that would make it easy to share code between the various drivers and selenium core, that allowed us to fix a bug in one place only and have that fix ripple out to every driver that made use of this mechanism. More importantly, it had to be easy to use, and for someone not familiar with a raft of languages and technologies to quickly get started with.

What would this mechanism look like? Well, there’s a few things that feed into this, but the most important one, was that a majority of the code we’d think of merging was querying the state of the browser (“find an element”, “get the value of this attribute”) and, as Jason Huggins would point out to me at the drop of a hat, the natural language for querying the state of a browser is Javascript. One of the nice things with Javascript is that it’s possible to get a nice, fast development cycle going in it. Just modify a test, save and then hit “refresh” in the browser. That’s kind of attractive. Better still, there are a lot of developers familiar with Javascript.

So, we decided to use Javascript.

Because this shared code was to be composed of the smallest useful fragments of functionality required for browser automation we decided to refer to them as “Browser Automation Atoms”, or “atoms” for short. Rather than write them from scratch, the easiest thing to do was to extract them from the existing code — this is stuff that’s been battle-tested, so we know it’s robust.

There was one very obvious fly in the ointment: not every driver is written in Javascript. Although we have a mechanism available in every browser for executing JS, it’s wildly inefficient to dump an enormous lump of code on to the JS engine of the browser whenever you want to query the DOM. After all, most of the code would not be needed, and not all JS engines have been created equal. Some are blazingly fast. Others, not so much.

It would also be nice to break the code up into manageably-sized modules, rather than being in a single, monolithic file, which implies some clever “module loading” capability. Except this code isn’t always going to be executing inside an environment where writing “script” tags to load additional scripts is possible. You can’t do that in the guts of a firefox extension, though you can load files other ways. However we tie modules together will need to cope with that.

Ah! These opposing requirements: small modules containing the functions we want to use, no extraneous code, and for everything to be in a single file in order to minimize the pain of loading additional modules. That doesn’t sound like a very compatible list. How we resolved those differences is the topic of my next post….

Create a free website or blog at

%d bloggers like this: