Fork me on GitHub
Showing posts with label watir. Show all posts
Showing posts with label watir. Show all posts

Monday, April 9, 2012

Future of ChromeWatir

I am reviving this blog again and as a first post I wanna write about future of Chromewatir, a work I did sometime back. ChromeWatir started when Watir had no support for Chrome browsers but since then the work on watir-webdriver has invalidated much of need for this and Jarib has done excellent work moving forward.

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

ChromeWatir + Watir-WebDriver Update [Important]

Interesting development in Watir world but not a completely unanticipated one. I started playing around with using WebDriver as platform for Watir in the form of FireDriver and ChromeWatir.

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://

Example code in watir-webdriver (ChromeDriver)

require "watir-webdriver"
browser =
browser.goto ""
browser.text_field(:name, "q").set "Watir"
browser.button(:name, "btnG").click

The code is same as Watir except the driver changes internally.
The repo is in Feel free to fork and enjoy...

Wednesday, November 11, 2009

Code Swarm Visualization of Watir Project

Presenting the code swarm visualization of Watir project. For those who don't know what is code swarm, it is an experiment in organic software visualization or what ever that means :). For me it meant visualization of activities on a code repo or project. So here is the one for Watir project. If you wanna watch it in Hi-def go over to Vimeo and take a look. Its pretty awesome...

Code Swarm visualization of Watir project from saivenkat on Vimeo.

Sunday, April 26, 2009

FireDriver => FireWatir + WebDriver Experiment

I think I have become the evil scientist in the Watir world creating all these experiments :). Well everyone knows the story. FireWatir is great especially after the integration with Watir and getting the same API. There are people out there working busy to iron out the differences in API and making things better. But the FireWatir world is not all perfect. The JSSH which FireWatir depends on to drive FireWatir by injecting JavaScript is a legacy code or more accurately an orphaned code (No maintainer). The code base is a black box (At least for me. Not sure for other but Angrez will know the internals). We know how to use it but any defects on its front has practically no owner. And there is no scarcity for defects also. The interface with firefor is also weak. Enough ranting. I think you get the picture. To make FireWatir better we must move away from JSSH.

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.

I didn't want to consume WebDriver jar from JRuby and wrap it up with Watir API as this will not help the people who use native Ruby. So I am actually using the JavaScript extension which is the core of the WebDriver's Firefox driver. This extension sits inside Firefox and drives it according to the commands which it gets over the wire in a JSON based protocol. If you need to know more details about the implementation, please check out the code in GitHub FireDriver project. There are a few things like setup the extension and install the gems which you need to do for now (They will be automated soon). The way to do this is in the Wiki. Again any help needed in this, please let me know.

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

JWatir, A Watir on JRuby Experiment

Edited 20 March 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

Watir, Is it good or just good enough?

Update - Added a few more points and links

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

ChromeWatir 1.5.0 Released

I am happy to announce that we have released a new version of ChromeWatir. You can get the gem or source from the project page. We have been working on it for quite sometime and it is me whom you should blame for doing a long spike on Chrome AutomationProxy which I did not complete till now :).

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.
ChromeWatir is still in alpha but we have got some really good feedback and support make it better. Thanks for everyone who helped and encouraged us.

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

Watir slides for Ruby and Bangalore BarCamps

I wanted to post a few things in this blog for quite some time. But I have started liking Twitter more as it does not make me type so much :). That is not meant to say that I will abandon this blog. I will be still posting here and keep things updated.

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

ChromeWatir new release is available!!!

It just feels like yesterday... And now we have a new release of ChromeWatir-1.4.0.

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)
This release has been quicker than we expected but a good one. Get the downloads from the project page.

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

Announcing the release of ChromeWatir

I am happy to announce that the first version of ChromeWatir has
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
downloads page.

Please have a try and give the feedback.

Friday, December 12, 2008

Announcing FlashWatir and Silverlight-Selenium

Well two of my open source projects have gone live. I am really happy that I can bring them open and it will be useful to people who want to test applications with these RIA technologies. I have always been an advocate of testability and whenever a new glossy technology comes testability goes for a toss and this has been a concern to me for a long time. With these two projects I hope I have played a small part in bringing testability for flash and silverlight.

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

Do we need to test hidden fields?

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.

In normal programming terms when writing unit tests we will not test the private members of a class because we will be exercising them from the public interface available. So there is no need to test the private members and if we feel we need to do then it means that we have some hidden complexity in the private method’s code which needs to be refactored. In the same lines the hidden field can be considered as private member or more appropriately private variable of the form. The value which goes into a hidden field may be directly filled in to create the query string or they may be manipulated by JavaScript before being used in to form post. If we need to manipulate the hidden fields we need to know all these implementation details and ask our testing code to do them, which is not a good idea.

This leads me to a question. Do we need to test or more preferably set values in hidden fields when we test an application? In my opinion we should not as hidden fields are private members of html language. It is better to their working through the form post or the JavaScript than us to deal with them directly and test them individually.