• What will happen to the Google Code website? I'm quite fond of it, but there's probably a discussion about how best to import the wiki and issues from Google Code to Open QA's infrastructure. I may just sit up one night and copy the issues across. This is something that we've chewed over before, so I'm happy to continue those discussions outside of this thread.

 

This probably relates to the overall rebranding and update of openqa.org. We all pretty much agree that once Watir leaves OpenQA (they are in the process of doing that), that rebranding OpenQA to Selenium makes sense. In doing that, we'd make http://selenium.openqa.org be the main website and likely merge the content from the other projects in to that template. At that point, we'll likely have a good opportunity to upgrade/update the infrastructure bits (website, bug tracker, forums, etc), including pulling in anything we like from Google Code or even adopting parts of it.

OK. I'll wait until the Great Rebranding before trying to move anything. Sounds like the easiest thing to do as well.

In general, I'm really excited about the work you're doing. I know we discussed in the past different ways to merge WebDriver in to Selenium, but perhaps you can reiterate your vision for how this will all work. Keep in mind the recent work Dan and Philippe have been doing. Specfically they modified the default modes of RC to use HTA mode, Chrome mode, and a privileged Safari mode.

Providing as flawless an experience as possible for our users is essential: Dan and Philippe have done entirely the right thing.

I see the process taking a reasonable amount of time to complete and being a gradual process. The plan in my head looks a like:

• Selenium 1.5: Merge the source trees and include the WebDriver interfaces and classes in the Selenium RC downloads. This is probably the crudest possible way to "merge" the projects, but it's a start. I would expect the "WebDriverBackedSelenium" class to be pass the Selenium tests, but I'd be amazed if it was flawless! I would love to see a "SeleniumBackedWebDriver" implementation too (anyone want to write that?)

• Selenium 1.6+: Start the process of merging the projects more closely. The initial focus would be to make the default implementation of the Selenium RC IE implementation use the WebDriver tech. We can also start to expose some of the WebDriver capabilities to Selenium, in particular our keyboard and mouse input methods (which will be completely native on Mac, Linux and Windows by this point)

• Selenium 2.0: A major revision number is our chance to review both the dictionary and object-based APIs, reassessing them in the light of how people use them and ensuring that they meet the original vision.

My feeling is that WebDriver integration comes in two parts:

 

 

• Improved browser automation (speed, reliability, additional automation outside of the DOM). Because chrome mode is pretty reliable already and WebDriver doesn't have great Safari support, my instinct is that the first candidate to replace is HTA mode and get WebDriver to become the IE automation engine for RC.

 

Agreed. HTA mode is the first candidate for moving over to the WebDriver tech. I suspect that the Firefox Chrome and FirefoxDriver will borrow aspects from each other: we're going to end up with a hybrid core of functionality and specific parts tailored to each of the APIs.

• Improved APIs for all languages. I think at a high level, everyone agrees that there are two ways to run Selenium today: using the simple language in IDE or using a programming language with RC. Unfortunately, the RC API sucks, so adopting the WebDriver-style API would be a big win for RC.

I agree that adopting the WebDriver API would be a big win for RC

I'm looking to support Java, Python, Ruby and C# as "first class citizens" of the WebDriver API. We've made a start with the Python bindings, as well as with the C# binding. I'm happy to go into detail about how we're planning on facilitating this if anyone's keen to join in the fun!

I understand that RC isn't the ideal place to do the integration, since part of what WebDriver brings to the table is not being "remote", so we need to figure out a way to reconcile that in to the overall vision. I don't have a great solution, but I figure it probably involves a new project as well as possibly merging RC and Grid together to a single "remote" solution.

You'll be pleased to hear that we've started addressing this issue already: there's a WebDriver Remote implementation that's already in trunk. It should be bourne in mind that eventually we're always going to be "local" to a browser, even if there's a chain of servers between it and the user, and we take advantage of this. Having said that, in the common case, where tests are running on the local machine, removing the server process is a win for the user, if only because it reduces complexity and there's one less thing to forget to start. In the case where there's a central server (or grid) having the remote interfaces is a real boon.

andras.hatvani wrote:

Hi Simon,

 

what do you mean by merging? Merging as a replacement, as an option or as a real merge by getting the best out of the two frameworks? Are they complementary, concurring or partially overlapping solutions?

I'm talking about doing a real merge. There are cases where the current Selenium approach is "better" than the WebDriver approach (such as running on the iphone!), whereas there are cases where the WebDriver approach is more appropriate or capable than Selenium's (such the IE driver) The strengths of one address the weaknesses of the other. I really believe that it's going to be great for our users.

What I read in the FAQ as main difference is that WebDriver controls the browser via the native API; I guess a similar way like Watir or WinRunner - both had drawbacks, too as does Selenium have as well, but other limitations.

To make a long story short: I'd love to read a feature comparison matrix to be able to decide which one to use in different projects.

The differences can be listed as so:

• WebDriver drives the browser natively, and can take advantage of the extended capabilities that this offers (such as avoiding the single host origin problem)

• It is a lot easier to support new browsers using Selenium's codebase --- all browsers run Javascript.

• The WebDriver API takes a fundamentally different approach to Selenium's. Which you prefer is a choice you and team can make.

• Selenium RC uses codegen to create the language bindings. This is fast, but not necessarily particularly idiomatic. We're hand-writing the other language bindings for WebDriver.

• When running the browser on the localhost, WebDriver doesn't require an external process

I will put together a more complete feature matrix. Is there anything in particular that you're keen on seeing?