FireWatir JSSH “Unable to connect” – FIXED!

Firewatir is awesome. But… sometimes Firefox takes too long to load (eg: if you have loads of plugins) causing firewatir to timeout and give the following error:

Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Firefox is running with '-jssh' option

This was a major pain; painful enough to send me looking through the firewatir code in the hope that I’ll be able to fix it. Turns out the logic that deals with starting firefox and establishing a connection to JSSH needs only a minor change to fix the problem. The relevant code is in the firefox.rb file within the firewatir gem, specifically the set_defaults method. Here’s a monkeypatch to override the necessary method:


require "rubygems"
require "firewatir"

class FireWatir::Firefox
  # fixes the timeout caused by firefox taking ages to
  # load, preventing a connection from being made to JSSH
  def set_defaults(no_of_tries = 0)
    begin
      $jssh_socket = TCPSocket::new(MACHINE_IP, "9997")
      $jssh_socket.sync = true
      read_socket()
    rescue
      no_of_tries += 1
      sleep 0.1
      retry if no_of_tries < 300
      raise UnableToStartJSShException, "Unable to connect to machine : #{MACHINE_IP} on port 9997. Make sure that JSSh is properly installed and Firefox is running with '-jssh' option"
    end
    @error_checkers = []
  end
end

To use the patch, place it in a file that is read in before you use firewatir for the first time.

Firewatir tries to connect 3 times to JSSH after waiting for 2 seconds for Firefox to load. This is usually enough. But again, there are scenarios where 2 seconds and 3 connection attempts just isn’t enough. The very simple and slightly hacky fix that I tried worked beautifully… instead of trying 3 times, try 300 times instead with a simple sleep 0.1 just before the retry. This gives Firefox around 30 seconds to get its act together. As soon as it is ready, the test begins. It hasn’t caused any execution slowdown – in fact, now that I don’t have to run ‘failed’ tests at the end of a test run, I can just run everything once, saving loads of time! The joys of one-click-testing…
Since putting in this fix, I haven’t seen the problem again!

Difficulty automating Maximo using WATIR

I’ve recently been trying to get WATIR to work with IBM/MRO’s Maximo Asset Management solution. I got somewhere but it was a bit of a pain.

I was able to log in and navigate to the “Service Orders” window. I even managed (with some help – thanks Anne!) to click the “New Service Request” button (yeah, it wasn’t easy and required a bizarre hack) and got to the stage where I could enter in the details to create the service request. Unfortunately, I got stuck when trying to find the names of the text fields in that window – they just can’t be found! It’s probably a result of the DOM manipulation that I think Maximo is doing, since the HTML in “View Source” doesn’t match up at all with what’s on the screen – it’s not even close.

The Firebug Firefox extension would probably have helped, unfortunately I couldn’t use it since Maximo AM doesn’t seem to work with Firefox at all.

So, I imported the text field that I wanted to use into a Rational Functional Tester script, and it worked fine. RFT had no problem locating the object. The object hierarchy was *huge*, but at least it worked. And when I ran a script that used the text field, that worked too. So, thinking that if I copied the name of the text field into my WATIR script WATIR might be able to find it, I made the change and ran the script. Unknown Object Exception. After struggling with this for a couple of hours I admitted defeat. Which I don’t do lightly.

If anyone out there has managed to automate Maximo AM using WATIR or if you’ve run into the same problems, I’d love to know how you got on and how (if!) you got round these problems.

Needs must…

Here’s a link to an article on O’Reilly’s perl.com site that talks about the experiences of a guy who couldn’t get access to a license for QTP… so he wrote his own test automation tool himself! Very cool! It’s interesting that WATIR has followed down the same road with its design around using Microsoft’s WIN32OLE interface to IE.

Anyway, check the link:

http://www.perl.com/pub/a/2005/04/21/win32ole.html

First Watir explorations…

I’ve put up a couple of posts saying that I’m going to look into watir. Well, here I am, looking into watir. And what do I see? Myself! Get it? Hahahahahaha!!!!!! You see what I did there? Heeeehehehehhehheeeeeheeeheeehee!!!!! Errr hrrrmmmm…. Excuse me.

In the next few articles covering watir, I’m going to be using “SafariWatir”, the watir implementation for the Mac – I only use windows when I’m get paid to. The code in the test cases will be the same, I’ll just be needing to ‘require’ a different library (that’s java/RFT-speak for “import”), that’s all.

Installation
So, I followed the instructions to get it installed (located here: http://safariwatir.rubyforge.org/). Ruby apps generally use a package management-like system to get themselves installed. The package manager is called “Gems”. Since I’ve already got Ruby on Rails installed on my machine, I had ruby gems already installed. So the total amount of work required for installation was running this on the command line:

sudo gem install safariwatir --include-dependencies

Well, there’s an improvement already! RFT takes ages to install (although it is very easy to do), and QTP is a pain to install. There really isn’t too much more to say about that, apart from it’s easy. Very easy. Nice. No licenses to agree to, no license servers, no careful storage of documents and CDs, just a single command line. Being a fan of simplicity and clean implementations, I am impressed.

First Script
Next, I want some sample code. There’s a very simple script on the same page as the install instructions (http://safariwatir.rubyforge.org/). Here it is:


require 'rubygems'
require 'safariwatir'

browser = Watir::Safari.new
browser.goto(“http://google.com”)
browser.text_field(:name, “q”).set(“pragmatic obtiva”)
browser.button(:name, “btnI”).click
puts “FAILURE” unless browser.contains_text(“Agile Retrospectives”)
Even before running the code to see what it does, the fact that the language used is Ruby makes it readily understandable just by looking at it. Side note: Ruby is a cool language – you’ll need to know it to use watir.

So, we have some code. Copy it into a text file and name it something – “thing.rb” in my case. Once saved, execute the file. Again, in my case this was done by running:
ruby thing.rb
Safari (the equivalent of Internet Explorer) opened, and the google homepage came up. It works! Victory! It really is that easy! Wow.

First Script Error
But there is a problem… I got the following back in the console:

ruby thing.rb
/usr/local/lib/ruby/gems/1.8/gems/safariwatir-0.2.3/./safariwatir/scripter.rb:436:in `execute': Unable to locate TextField element with name of q (Watir::Exception::UnknownObjectException)
from /usr/local/lib/ruby/gems/1.8/gems/safariwatir-0.2.3/./safariwatir/scripter.rb:144:in `focus'
from /usr/local/lib/ruby/gems/1.8/gems/safariwatir-0.2.3/./safariwatir.rb:296:in `set'
from thing.rb:6

Interesting. Even with only a cursory knowledge of ruby and watir, the problem is fairly obvious: it can’t find the text field called “q”. After looking at the source for google’s homepage, I can verify that there is a text field called “q”. So what went wrong? Hmmm….. Run it again… ….This time it works!?

And now my feet are back on the ground. The reason it failed is obvious. The line of code that looks for the text field (browser.text_field(:name, "q").set("pragmatic obtiva")) is executed before the text field exists. When I run the script a second time, the text field does exist as the window from the previous run is still there and the page comes up from the cache – much quicker than getting the page off the tubes.

Fixing the script
In RFT, I’d put in txtQ.waitForExistence(); and this script defect would be fixed. Does watir have an equivalent? Hmmm… can’t find one that works. Supposedly, I can with the following line:
browser.wait
But that doesn’t work.

Another thing… Each time I run the test (well, all times but the first), safariwatir doesn’t manage to type out the whole “pragmatic obtiva” string. The search value has been “pragmati”, “pragmatic obti”, “pragmatic ob”, and “pragmatic obtiv”. This is not good. If an automated test is not repeatable, it isn’t worth anything. What is going on?

Temporary setback
It’s late, I’m off to bed. I’ll try again tomorrow. So far, I’m impressed. I think the problems are having are more due to my ignorance of watir/ruby/safariwatir than the software – that’s usually the way.

More WATIR news…

It looks like WATIR is becoming more and more tempting to use as a full-blown test automation tool… The one thing that was keeping me away was that it only works with Microsoft Internet Explorer. No more! I’ve discovered that it now works with FireFox and Safari on the Mac. Cross-platform regression testing of webapps using the same automated test tool is now posible. Absolute Genius.

Once I get through my shiny new “Agile Web Development with Rails”, I’ll be looking at WATIR in earnest.

WATIR – Web app testing with Ruby

I’ve recently been learning the ruby programming language. Compared to Java, it is a dream. It’d be great if RFT allowed writing tests in it – it’s probably already possible using JRuby but I haven’t had the time to look into it.
What I have found is a web app testing tool written in ruby called WATIR. I’ll be investigating it over the upcoming holidays. If it is anything like what it advertises itself to be…

Initial drawbacks:

  • WATIR seems to be windows-only; I hope I’m wrong
  • WATIR only seems to work with IE, not FireFox. I may be wrong… I hope I am…

With something like this, it’d be a shame if it didn’t move to be cross platform. If gecko-based browsers on Win/Linux/Mac and the KHTML/Webkit based browsers (Safari on Mac, and Konqueror on Linux) were supported as well as Win/IE, WATIR could be something big. After all, with the rise of the so-called “Web 2.0″ apps and the growing irrelevancy of the OS, cross-platform/cross-browser regression testing could become far more important than it is now.

We’ll see what happens with this one…