On Wed, Jan 27, 2010 at 11:38 AM, Ethan <[email protected]> wrote: > I'd be very interested to hear what you think are significant >> shortcomings of the WebDriver approach. >> >> > Basically it seems to me to add an unnecessary layer of complexity. Watir > can talk to a browser - firefox, for example - directly through an extension > (JSSH). or it can talk to another piece of software (webdriver) which in > turn talks to firefox through some other piece of software (FirefoxDriver, I > think?). Why is the latter advantageous? >
JSSH is a nightmare. It's a compiled c++ extension, which means it needs to be compiled for every platform as well as significant updates to Firefox and there does not appear to be an owner currently for that project. Having worked a week or two ago to try to compile it for Snow Leopard (64bit) and Windows 7(64bit) as well as now trying to compile it with FF 3.6, and if you take a look at the current matrix of jssh extensions, we're lucky enough to have them compiled by a few different sources. Webdriver has a FF extension which doesn't need to be compiled, and serves as a good driver that we can use, particularly with Jari's work to pump commands into it. It should actually simplify things from the developer perspective, and not complicate things from the user perspective. Those are key tenets of moving over to Webdriver, without those in mind, you're right, it would be needless complexity. Hopefully that makes sense. :) > > One argument is that the other piece of software moves browser-specific > implementation stuff out of watir's code. But, really, the DOM is not too > terribly different from browser to browser; if you have the same access to > the DOM, much of the implementation is the same (which is why I have been > able to move so much code from firewatir and ie-watir to commonwatir). It > seems like a lot of the point of watir itself has been to move > browser-specific implementation stuff to where users don't have to worry > about it; if webdriver does this, why is watir needed at all? (apart from > familiarity with its api and code that it would be a pain to migrate, I > guess.) > Interesting question. Same question comes up all the time in regards to why Watir vs Selenium. My answer is the api and simplicity of use. Watir is, in my mind, all about the api and ease of use. Selenium's api and ease of use is less than ideal. I suppose I could go into more details, but that sums up my general feelings. Happy to talk more about it though if you do want. > > I do not mean the above to be very strong or definitive reasons - more > preliminary impressions, as am not too well-informed as to the details of > how webdriver/selenium talk to browsers. I do not intend to be bashing a > thing that I do not know very well. I would be quite interested to know what > advantage using webdriver provides, if you want to explain. I do plan to > look more closely into webdriver and selenium, and if reasons to use them > are compelling, then possibly looking into moving my own work in that > direction as well. > Well, I'd definitely recommend taking a look at Selenium if you haven't already. Selenium and Watir are the Coke and Pepsi of functional testing in this space. I took a look at both when choosing an open source solution 4 plus years ago and chose Watir; Bret and I know the core developers in Selenium fairly well. I talk to Simon(webdriver) and Jason Huggins fairly often. That being said, having people contribute who get involved in the Watir community is important to us as an open source project. Hopefully you'll continue to work with us and become part of the community. :) Cheers, Charley > > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development >
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
