Monday, April 9, 2012
I still get queries about ChromeWatir in this blog or through email after reading the blog. Please use watir-webdriver instead as it is continuously maintained and solidly built and I am discontinuing ChromeWatir.
And now for something completely different....
Wednesday, January 13, 2010
Yesterday Jarib has released a Watir abstraction on top of WebDriver. I am planning to move the effort of working on ChromeDriver to Watir-WebDriver which has ChromeDriver in it.
Installation of Watir-WebDriver
> sudo gem install selenium-webdriver
> git clone git://github.com/saivenkat/watir-webdriver.git
Example code in watir-webdriver (ChromeDriver)
browser = Watir::Browser.new(:chrome)
browser.text_field(:name, "q").set "Watir"
The code is same as Watir except the driver changes internally.
The repo is in http://github.com/saivenkat/watir-webdriver. Feel free to fork and enjoy...
Wednesday, November 11, 2009
Sunday, April 26, 2009
Thus this experiment started, an effort to save FireWatir from Jssh. Looking at the options, I really like the way WebDriver works with the browsers through native code layer to automate them. I think Bret and Charley will agree with me on this. So with Simon, Bret and Charley's help I set out to do a spike on using WebDriver's Firefox driver to drive Firefox from Ruby to use it with Watir.
The solution is not perfect yet. It is an experiment. There are synchronization problems. The API is very small. I am working on this to make it evolve better. If you wish to contribute please fork the repo and start working on it right away. Thats the GIT way :).
Thank you Jijesh for helping me in this. Thank you Bret, Charley and Simon for supporting me.
Thursday, March 19, 2009
I have been seeing a lot of posts in Watir mailing list about JRuby support for Watir. I have always wanted this as I would like to use it with other Java libraries out there. The major stumbling block in making Watir with JRuby is the support for win32 ole support. And by the trend in which JRuby is developing, I don't think that this support is going to happen any time soon.
I found there are different ways to solve this problem. One was using something like Jacob to control COM components from Java or JRuby. But using Jacob I need to build everything ground up by myself. So the next natural choice was the consume the WebDriver's IE driver. I wrote a small wrapper around IE driver to expose that as Watir API and am calling it JWatir (Help from anyone who has better sense of naming libraries is welcome).
The code is available here in watir mailing list.The functionality is really small and supports only text field and button. There is a quirks in running the code. The webdriver's InternetExplorerDriver.dll, available inside webdriver-jobbie.jar needs to be extracted and somewhere in the system accessible path. Once the dll is placed, the test can be run...
The code is still at a very initial stage and mostly a kind of hack. It has practically no test coverage also except for the Google search example I have written. So no serious applications with JWatir for sometime except for developing it further :).
One more thing, I will also be moving it to GitHub soon. Any comments and views are welcome.
Thank you Simon and the webdriver team for creating a wonderful and solid webdriver API.
Sunday, February 22, 2009
When I was going through a few things to find some info, I found a lightning talk by Alister Scot about Watir at AWTA. The concluding thoughts struck me and made me think for quite sometime. It read "Should Watir be really good at a few things (IE, Firefox testing) or just good enough at a lot of things (IE, Firefox, Chrome, Opera, Safari...)?". Interesting point...
As an active Watir user and author of ChromeWatir, I would like to present my point of view on this subject. A lot of people will already be knowing this but I just wanted to write something about this for sometime and this point has given me this opportunity.
I feel that Watir has seen a huge paradigm shift especially in the last year. My thinking is, it has shifted from being a test driver implementation to an API to which individual drivers conform to. If you see my slides on Watir, please take a look at the slide Watir Architecture. In there I have separated the Watir API and the individual implementations.
There are several advantages for this approach. One is for the end user he needs to learn only one API to write test for any browser. As well it will be possible to switch the browser he is testing by changing the implementation. But a bigger advantage for the Watir developers is individual implementations are being done by seperate teams. So even though Watir supports different browsers, there will be individual teams which will be responsible for developing as well as maintaining them.
Keeping the interface separate is really important for this. The implementations need not be merged. This will help in delegating the responsibility to individual teams. In future we have have even more implementations but there will always be people who know about the implementation to take care of these. So if we take this point of view into consideration, I think we don't need to care about Watir being just good enough. Watir will always be good.
Well talking all the green and lush things is good. But I like to think on both the sides of the problem. The problems I see in this approach are except for the mainline IE implementation, all other Watir implementations seem to be young and some differences from the original one. It may take sometime for them to stabilize and get on the same platform as the original implementation which is understandable.
As well getting disparate teams to work together may be difficult as they will have a different way of working. There is no ready made solution to this but I would love to know your thoughts on this.
Let me know your thoughts about this?
Friday, February 20, 2009
What is new in this release
- Support for table and file field elements
- Support for Element Collections like links, images, etc.
- Refactoring and fixing defects in launcher code.
Now that we are done with the release, I think it is time to start working on C++ code to use AutomationProxy for the next release now ;).
Tuesday, February 17, 2009
Anyhoooo I am speaking at RubyFunDay and Bangalore BarCamp about Watir. Here are the slides for the talk. If you are there, let me know. We can discuss on Agile Testing, Opensource testing tools, Polyglot stuff and Watir.
Wednesday, January 21, 2009
Whats new in this release?
- Support for element containers like frames, SPAN, div.
- Refactored the locators and made them better :)
- More test coverage and improved doc. (Check out the wiki)
Future releases... They are quiet far ;). We have lots of things planned. Using the Automation Framework of Chrome is one of them. Compatibility with Watir API, support for table and element collections are also in the list. If you have anything in mind, add it to the wish list we will be putting up in the wiki soon.
I also added the ChromeWatir page in the Watir wiki. Check out the page here.
Download the gem, install, use and let us know the feedback.
Friday, January 9, 2009
been released today. The API follows a similar convention to Watir for
Google Chrome browser. Please visit the ChromeWatir Google code
website for more details
We are in the process of making it better by stabilizing it as well
adding more functionality.
The first release is available as gem as well as source in the
Please have a try and give the feedback.
Friday, December 12, 2008
For those who want to use it flash-watir is available as a gem as well as source in SVN. Please visit the FlashWatir Google Code Project. Read the docs, play around with the source. If you have any questions or want to contribute, let me know.
Silverlight-Selenium is available as of now in Java (I know silverlight is .Net stuff :D but it won't take long to write it in other languages). Please visit the project Silverlight Selenium.
Let me know if you have any questions or feedback.
I thank Paulo Caroli for helping me out in understanding flash testability. As well pairing with me for silverlight-selenium and showing how to do TestDriven Development :). Thanks for Jeya for pairing with me and setting up the silverlight ennvironment.
P.S. Work on silverlight extension for Watir in on the way.
Tuesday, August 26, 2008
I got into this moral dilemma when I was writing the schnell-driver’s hidden field (input type="hidden") tests. When I was writing the schnell with htmlunit I used something close to Watir API and so I wrote the hidden field tests especially had the hidden set values as a part of the test suite. But when writing the webdriver porting I suddenly got into the question of the need to test the hidden field set value tests.