After a year and a half of work, Selenium and WebDriver are almost one. The two projects will merge to form Selenium 2.0, the open-source cross-browser Web testing framework. The fruits of this merger should allow existing Selenium users more flexibility for their tests, while remaining backwards compatible. Selenium 2.0 entered beta just before the end of 2010, and is nearing a final release candidate.
Simon Stewart, creator of WebDriver, explained the merger in an e-mail to both communities in August of 2009. “Why are the projects merging?” he asked. “Partly because WebDriver addresses some shortcomings in Selenium (by being able to bypass the JS sandbox, for example. And we’ve got a gorgeous API), partly because selenium addresses some shortcomings in WebDriver (such as supporting a broader range of browsers), and partly because the main Selenium contributors and I felt that it was the best way to offer users the best possible framework.”
WebDriver uses browser-native control mechanisms to execute its tests, rather than relying solely on JavaScript, as Selenium does. WebDriver manifests as an extension in Firefox and uses the Internet Explorer automation controls, resulting in a more versatile testing tool than Selenium. Selenium, because it is written in JavaScript, is beholden to browser security models and is thus limited in its ability to truly test applications without restrictions.
Jason Huggins got started with Selenium at Google, where he ran the search firm’s internal Selenium testing cloud. He has since left Google and founded Sauce Labs, a firm that sells access to its own Selenium testing cloud. Huggins said version 2.0 will support Android and iOS for the first time.
Support for these mobile devices will come thanks to WebDriver: Both devices are supported through browser plug-ins. Users will be able to run tests directly on an actual handset, or within an emulated mobile browser environment; the plug-in functions in both scenarios.
But, said Huggins, one fundamental problem for Selenium users still remains: maintaining large numbers of tests can result in long build times.
“We kind of had a happy accident,” he said. “We set out to solve the No. 1 problem: that Selenium tests take too long. But the first problem is that it’s hard to set up, and once it’s set up, the tests take too long.
“The happy accident was discovering that the other, actually bigger problem was the setup and maintenance of having a test lab. You have 100 machines, and you put IE on these 50; then a new version of Firefox comes out, and if you’re a lab manager, do you go through the procurement process to get more Firefox machines? It becomes this full-time job to stay in place. Add to that the fact that browser vendors are racing to the bottom; Google Chrome is releasing daily. If you are in the position of being that QA guy, you are massively under siege.”
To that end, Sauce Labs’ test cloud records videos of failed tests and presents them to developers at the end of the run. Huggins said that using an automated cloud of Selenium test systems can speed up build times by spreading tests across multiple machines.
Huggins said that Selenium 2.0 will be a major boon for testers used to working with the previous version. A great deal of work in Selenium 2.0 is focused on maintaining compatibility with version 1.0, so that existing tests will not have to be rewritten.
