Alan Baird and Jari Bakken on watir-webdriver

On January 28, 2010, Alan Baird (<alan_baird>) and Jari Bakken (<jarib>) had a chat about watir-webdriver on #watir IRC channel at freenode.net. Published with permission.

[14:29] <alan_baird> jarib: if you are still around I have a follow up webdriver question for you
[14:36] <jarib> alan_baird: shoot
[14:36] <alan_baird> ok
[14:36] <alan_baird> so, in the podcast, Simon says that Webdriver is built on top of html unit
[14:37] <alan_baird> is that correct?
[14:38] <jarib> it has several backends
[14:39] <jarib> htmlunit being one of them
[14:39] <jarib> in addition it drives IE, Firefox, Chrome, with support for Opera, iPhone and Android on the way
[14:39] <alan_baird> ok
[14:40] <jarib> was the podcast that confusing? ouch :/
[14:40] <alan_baird> so, it seems kind of analagous to what a JVM does for different operating systems?
[14:40] <jarib> i guess we ended up talking too much about HtmlUnit
[14:40] <alan_baird> well, I don't know that it was all that confusing
[14:40] <jarib> you might say that
[14:40] <alan_baird> but, in trying to type up the show notes I've come up with my own questions
[14:41] <jarib> it gives you a common interface to the various browsers
[14:41] <alan_baird> ok
[14:41] <alan_baird> so, that common interface is written in Java right?
[14:41] <jarib> not really - there's bindings in java, ruby, c# and python
[14:42] <jarib> the java and ruby bindings are the most complete
[14:42] <alan_baird> ok
[14:42] <alan_baird> i guess I'm not real familiar with the bindings concept, but I guess I can get the gist of it
[14:43] <alan_baird> but basically there is this thing at the core (webdriver) which can talk to the browsers natively
[14:43] <jarib> alan_baird: these slides may be helpful: http://docs.google.com/present/view?id=dgpzbjs_33cxsxd9dd
[14:43] <jarib> check slide 11+
[14:44] <alan_baird> k
[14:44] <alan_baird> looking...
[14:44] <jarib> also slide 27 is telling :)
[14:44] <jarib> although the c# side is mostly complete as well now
[14:45] <jarib> alan_baird: there's not really a "core" - webdriver speaks to each browser through the mechanism that fits that particular browser the best
[14:45] <jarib> so for firefox and chrome it's through their extension system
[14:45] <jarib> for IE it's C++
[14:46] <jarib> for opera (when it's released) it's using their scope protocol (which is also used by their built-in JS debugger)
[14:46] <jarib> etc.
[14:48] <alan_baird> seems like this webdriver.h is kind of at the core of all of this?
[14:48] <jarib> only for IE
[14:48] <alan_baird> ok
[14:49] <jarib> for FF, there's a firefox extension, for example
[14:49] <alan_baird> so, when you wrote selenium-webdriver, you didn't have to worry about all of the different browsers though did you?
[14:49] <alan_baird> (cause, that's what webdriver's supposed to do right?)
[14:50] <jarib> alan_baird: nope, i had to worry about them
[14:51] <alan_baird> hmm
[14:51] <alan_baird> well, how did having webdriver make things easier?
[14:52] <jarib> before i started, they had code that would bridge java->firefox extension, java->C++ IE driver, java->chrome extension etc.
[14:52] <alan_baird> (btw - I'm typing this in the middle of an ice storm, so if I suddenly disappear and don't come back it's probably cause the power went out)
[14:52] <jarib> so i basically ported the java parts to ruby
[14:52] <jarib> so now you also have ruby->firefox extension, ruby->C++ etc
[14:53] <alan_baird> ic
[14:53] <alan_baird> and that's what selenium-webdriver is right?
[14:53] <jarib> it made it easier since i could reuse those browser-specific parts
[14:53] <jarib> yes
[14:54] <alan_baird> so, i looked at some of the examples in selenium-webdriver, would it be correct to say that that gem's api follows selenium's existing api?
[14:54] <jarib> how the "language bindings" talk to the browser still differs somewhat from browser to browser
[14:54] <jarib> alan_baird: it's more correct to say the webdriver API
[14:54] <alan_baird> ok
[14:54] <jarib> although "webdriver API" =~ "selenium 2 api"
[14:54] <alan_baird> got it
[14:55] <jarib> however "webdriver API" != "selenium 1 api"
[14:55] <jarib> most people associate "selenium" with the selenium 1 api
[14:55] <alan_baird> cool...ok now how does webdriver remote come into the picture
[14:55] <alan_baird> is it required?
[14:55] <alan_baird> why would you use it?
[14:56] <jarib> the remote is basically two parts: a java web server, and a client driver
[14:57] <jarib> the server will accept commands like "click", "findElement" (using a REST-like JSON-over-HTTP interface)
[14:57] <jarib> before they had java client->java server
[14:57] <jarib> now we also have a ruby client for that server, so ruby client->java server
[14:57] <jarib> does that make sense?
[14:58] <jarib> it's not required, but it's useful if you want to run your tests launch the browser on another machine
[14:58] <alan_baird> is that kind of the replacement for Selenium Grid?
[14:59] <jarib> say, if you're developing on linux, you could easily run your tests on IE on windows, firefox on mac etc. using the remote driver
[14:59] <jarib> no, Selenium Grid is more than that
[14:59] <alan_baird> ok
[14:59] <jarib> but the webdriver remote stuff could be used to build a similar system
[14:59] <alan_baird> well, right now, I think I kind of have the same thign
[14:59] <alan_baird> i have a bunch of VMs that I execute tests on
[14:59] <alan_baird> and a system that tells the vms when to run the tests
[15:00] <alan_baird> but, it seems like the remote would be one computer telling the other computers what to do
[15:00] <alan_baird> as opposed to having it be independent the way I do it now
[15:00] <jarib> right - with the remote, you wouldn't need to distribute your test scripts - each command to the browser would go over the network
[15:00] <jarib> so it's a long-running server process
[15:01] <alan_baird> thats pretty nifty
[15:01] <alan_baird> is that the main way people would use that kind of feature for?
[15:02] <jarib> yeah - also makes it easier to test on various combinations of browsers/platforms
[15:03] <alan_baird> i'm just noticing the slide that says Webdriver has a "lovely API", but apparently we didn't consider it lovely enough so we made watir-webdriver
[15:03] <alan_baird> :)
[15:03] <jarib> haha
[15:04] <jarib> well, compare it to the selenium api
[15:04] <alan_baird> i guess that's mainly so people could backport their watir tests without a major rewrite
[15:04] <jarib> yeah, for my part it's mainly because we have a lot invested in the watir api
[15:04] <alan_baird> right
[15:04] <alan_baird> same here
[15:04] <alan_baird> :)
[15:05] <alan_baird> ok, well thank you very much for letting me bug you
[15:05] <jarib> if i were starting from scratch with experienced developers, i'd probably use the webdriver api directly
[15:05] <jarib> no problem
[15:05] <alan_baird> i'm going to forward this conversation to zeljko
[15:05] <jarib> yep
[15:05] <jarib> do that
[15:05] <alan_baird> maybe we might do a little follow up