January 22, 2013
January 14, 2013
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
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
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
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
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
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.
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.
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.
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
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.
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.
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.
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….