A new committer and ChromeDriver
Simon Stewart
I've always wanted to say that, and I guess now's a good a time as any
because there's not just one, but two pieces of good news :)
First off, I'd like to introduce a new committer to the webdriver
project: Andre Morujão. He's been working on the brand new
ChromeDriver, which is currently living in a branch[1].
That's the second piece of good news: that we've now got a
ChromeDriver. Obviously, there are still some rough edges to be worked
through and functionality to be added, but it's fantastic to see such
a great start, and once it's ready we'll move it into the trunk of the
project. I think we can agree that Andre's made a fantastic
contribution to the project. If anyone is interested in pitching in
and lending a hand, now's a great time to get involved!
Cheers,
Simon
[1] http://code.google.com/p/webdriver/source/browse/branches/chrome
Mirko Nasato
I guess this also means that ChromeDriver will adopt the third option you mentioned yesterday, i.e. driving Chrome directly rather than wrapping the WebKit library?
Cheers
Mirko
Simon Stewart
Andre's done a lovely piece of work. Interestingly, the ChromeDriver
is very much a hybrid of the existing Firefox and Safari drivers. I
suspect that we might be able to make things nicer still once we
understand the commonality between Safari and Chrome, possibly sharing
the various commands and actions.
It's interesting. My personal philosophy is that tests using an actual
released browser and more conducive to making people feel confident
that an application will work as expected once it's in the hands of
real users, so this approach has a lot of benefits. OTOH, I'm sure
that there are still perfectly valid reasons for wrapping WebKit
directly (not least because it would facilitate headless testing) It's
also an interesting exercise in software development too :)
Cheers,
Simon
Mirko Nasato
Cool. I wasn't suggesting that wrapping WebKit would be better, just curious about which approach had been adopted.
I just hope to be able to test at least one WebKit-based browser on both Linux, Mac, and Windows at some point. ;-)
André Morujão
There's definitely a lot that can be reused between the ChromeDriver and other drivers - mostly because I was looking at other driver implementations to try to adhere to their conventions, and I saw a lot there that also worked for me :)
So I guess one of the next steps will be to try to understand what can or should be reused between these different driver implementations and refactor the code in the branch to avoid as much duplication as possible.
Just as a quick summary, the way it works now is by starting up Chrome with a flag that allows you to connect to it via telnet, and from there we can connect to the V8 debugger and thus evaluate Javascript expressions in the context of our tab.
This was more of a proof of concept, as it has a few limitations (e.g. I think when you start Chrome with that flag you can't have any other running instances, or else it won't work), but it seemed like a quick way to provide a working driver - or close enough ;-) - which some people might be needing.
The driver could still go in different directions (if Chrome ever allows something equivalent to Firefox's extensions, perhaps it would make sense to port the FirefoxDriver extension to it and use that instead?), but for now I'll try to polish a bit this implementation and we can think about alternatives sometime in the future.
Cheers,
André