My friend James has been using watir-webdriver to test his latest work. He was having trouble with Firefox prompting for the location to save files, which blocked the scripts he was running. While I’d like to claim some credit for pointing him at some helpful links, I think my real contribution was limited to being a friendly ear.

Anyway, he figured out how to fix this by changing the profile that Firefox runs with, so now you won’t have to. Check out his solution at http://jamesladdcode.com/?p=338

A frequently asked question for Watir seems to be whether there are any “record and playback” tools.  While most of the references point to a somewhat old tool, two viable alternatives seem much harder to find for some reason.

The first is Webmetrics‘ Global Watch Script recorder, available at http://www.webmetrics.com/products/script_recorder.html

The second, is CubicTest.  This uses SeleniumIDE to record the test, but can generate a script for Watir.

(Update) A third is the Testwise Watir Recorder, a Firefox plugin which I looked at a while back, but am unsure of it’s current state.

These will only get you so far, and have their own limitations, the most obvious of which is some corporate applications which only work in Internet Explorer. If a recorder is what you need though, there are a few options and these may get you further.  At any rate, hopefully they’re now easier for people to find.

I’ve been finding popups in Watir a pain of late, with most of the solutions on watir.com not working for me.  Finally today, I found something that worked.  Steve Swanson’s solution did the trick.

However, before it could work, I had to figure out that the AutoIT dll wasn’t correctly registered.  If you try the solution above and find it to be behaving mysteriously, then try the steps on Watir.com’s FAQ page.

I’ve just updated my celerity gem and it seems to fix all of the warnings that were flooding my scripts before.

Performance is still a touch disappointing with our website, but the changes make it much more usable (and there’s an option to turn javascript off now according to the docs at http://rubyforge.org/forum/forum.php?forum_id=34490).

Since reading about Celerity, I’ve been excited by the idea that I might be able to take my Watir scripts and run them more quickly by using a browser simulator. It also raised the possibility of taking scripts and running them in different environments and on different platforms, because Celerity runs under JRuby without a browser. It makes http requests directly, and simulates javascript behaviours without actually rendering pages.

I had the hope that this would give me an option to get quicker feedback from my automation. Unfortunately, this hasn’t turned out to be the case for the applications I’m currently testing. Simulation of the javascript on the page seemed to take longer than the real browser. I got quicker feedback by turning off images, blocking certain external hosts and using Internet Explorer. I still hold out hope that Celerity may improve performance, or that the applications I’m testing will be less javascript intensive.

Once I set to getting my Watir scripts working with Celerity, I needed to overcome a few issues. The last of these was the number of differences between Celerity’s behaviour and Watir’s behaviour. Resolving this turned out to be reasonably simple, and the same strategy for getting consistent behaviour between Celerity and Watir driving IE turns out to solve some other problems with differences in behaviour in Watir’s drivers for IE and Firefox.

My first cut at this is by no means complete, with a bunch of unnecessary duplication that can be easily factored out. For now however, it gets the job done, and may be instructive for others.

The strategy is simple -

- Wrap the browser in your own class.
- Dynamically require the appropriate library for the driver you need
- Create your own methods that provide consistent behaviour for the different browsers. In my case, I needed to be able to get the actual html content of the page after it had been modified by scripts running on the page. Each driver (IE, Firefox, Celerity) required a different method to be called to achieve consistency, but using this approach, I can call browser.html and get (almost) the same result from all browsers and drivers.
- Intercept any calls to methods that you haven’t implemented and pass them through to the actual browser object.

This is the first time I’ve touched Ruby’s method_missing method, and it was pretty painless.

There are a few issues getting JRuby up and running with Celerity on windows as well. I’ll describe these shortly in another post. I’ve also recently had issues installing the latest version of Watir, and will detail the solutions to these as well.

Sample code is below. Note that you can actually do without assigning the browser to a global variable, but I provide this example just to show how you can fit this new solution into the ’standard’ Watir approach. If you modify things so that you can specify the driver from the command line, you should be able to run tests using something like -

jruby main.rb –driver :celerity
ruby main.rb –driver :watir_ie
ruby main.rb –driver :watir_ff

----- driver.rb ------
require 'singleton'
require 'rubygems'

class Driver
    include Singleton

    def set_driver(driver)
      @driver=driver
      if @driver==:celerity
        require 'celerity'
        @browser=Celerity::Browser.new
      end
      if @driver==:watir_ie
        require 'watir'
        Watir::Browser.default='ie'
        @browser=Watir::Browser.new
      end
      if @driver==:watir_ff
        require 'watir'
        Watir::Browser.default='firefox'
        @browser=Watir::Browser.new
      end
      return @browser
    end

    def html
      return @browser.document.body.innerhtml if @driver==:watir_ie
      return @browser.xml if @driver==:celerity
      return @browser.html if @driver==:watir_ff
    end

    def initialize
      @browser=nil
    end

    def method_missing(method, *args)
      @browser.send(method, *args)
    end
end

----- main.rb ----
require 'driver.rb'

driver=:watir_ff
#driver=:watir_ie
#driver=:celerity

Driver.instance.set_driver(driver)
$browser=Driver.instance
$browser.goto("http://www.quinert.com/blog/")
puts $browser.html

Alister Scott, an Australian tester located in Brisbane has started a blog. There are a few Watir samples, and it’s always nice when a test automator puts their code up for scrutiny. I know my plans to do the same have taken far too long.

Check his writing out at http://watirmelon.wordpress.com/

In response to Matt’s comment on the robustness of my Tiny MCE Watir solution, I’d like to point out that the main threat to the solution’s value for me is that I can no longer run the automation in the background. Send_keys seems to need the IE window to be the topmost window. A lot of my Watir use is for tool-assisted testing rather than complete automation, so being able to leave a script running, go and do other things, then come back when the script has finished is a bit of a problem for me.

Anyway, I’m sure if you are running scripts as part of a build, or have a separate machine that handles all of your test execution, this is going to be fine for you. For me, it’s not quite what I needed. Just remember, quality equals value to some person…

The concept of inattentional blindness has been, if you’ll excuse the unintended pun, brought to the testing world’s attention lately by Cem Kaner and James Bach. Sajjadul Hakim has written recently on an exploratory testing experience in which he attributed failure to observe a bug to inattentional blindness.

While this may have been the cause, it is worth pointing out that our attention is a fragile thing. Inattentional blindness is but one of the ways that our brains can let us down while testing. Here are a few more:

Attentional blinking

If something grabs our attention, then something else happens almost simultaneously, or just after, we may miss it.

Inhibition of return

If something happens somewhere where we were just looking, we are less likely to see it.

Negative priming

Our brain applies filters to suppress things that are not relevant to the task at hand. These filters can arise through conscious effort or can happen if we perform a task long enough. An example of this is ‘banner blindness’, where things appearing in the spots where website advertising usually appears are highly likely to be ignored.

I became acutely aware of this effect last year. Steve Irwin had just died, and the news came to our team via a phone call to a teammate. I immediately jumped on CNN’s website, looking for confirmation. “There’s no news of it here,” I confidently claimed to the rest of the team. I looked back at the screen, and scrolling across the top of the page was a ticker, proclaiming Irwin’s death as ‘Breaking News’. It’s position at the top of the page, where advertisements usually appear, had caused me to skip straight over it.

Our brain is able to put filters in place to help optimise our performance of common tasks. These effects can last for more than a month after we have stopped performing the task that caused the filters to be put in place, just in case we need to do it again.

Our brain’s processing power is limited. In addition to the above problems, sometimes there’s just too much for it do deal with. It has developed tricks to help us survive lapses of attention, but these are also things that can catch us out as testers. The act of operating the product in order to test it is something which focuses our attention. By doing so, we blind ourselves to some problems.

I play video games with a kind of unfocused stare, and I suspect this actually helped me detect different kinds of problems when testing games, while probably making me blind to others. I find I can’t usually test applications with that protracted stare. I can however observe the application this way by putting the application under computer control, or by observing a playback of a recorded session. Video recorders and Watir scripts are great for this, and give you the chance to find different problems. James Bach also frequently recommends Spector for recording testing sessions.

Strategies

There are plenty of strategies for reducing attentional failures. Mix these up over the lifetime of the project for best effect. Some of them I’ve described already, but others I leave for you to Google -

- Rotate people through projects and tasks to avoid negative priming.
- Negative priming effects are reported to be reduced by alcohol consumption. Have a drink at lunchtime. Tell your boss science says it’s OK!
- Pair up…Maybe even with non-testers or people who have nothing to do with the project.
- Use recording tools and go back and review your testing sessions.
- Automate operation of the product, sit back and observe. I’ve used this technique, and Jonathan Kohl has success stories to tell as well.
- Blink testing. This is a defocusing strategy popularized by Michael Bolton and James Bach. Find different problems in test results, fast, by taking the detail out of them and scrolling through them quickly or zooming out.

If you would like to find out more, check out the book Mind Hacks: Tips & Tricks for Using Your Brain (Hacks). It’s a great primer on your brain, how it works, and how it can let you down. The ‘Developing Intelligence’ blog is also another great source of information and ideas.

I’ve spent far too much of the last day and a bit trying to get Watir to identify and manipulate the TinyMCE rich text edit control. Hopefully the title of this post will allow anyone experiencing similar problems to Google my solution!

TinyMCE does a lot of javascript nastiness (from Watir’s perspective), turning a text area HTML tag into a funky iframe WYSIWYG text editor. Watir seems to have trouble doing much with it, but I was finally able to get an acceptable (for now) solution:


#Substitute your TinyMCE editor instance for 'mce_editor_0'. It will probably usually be OK though.

$ie.ie.Document.parentWindow.execScript("tf=document.
getElementById(\"mce_editor_0\");tf.contentWindow.focus()")
$ie.send_keys("Hello there")


It’s not nice, but it sure beats yesterday’s solution:

20.times{$ie.send_keys("{TAB}")}
$ie.send_keys("Hello there")