Can a Watir Browser Object Be Re-Used in a Later Ruby Process

Can I initialize a Watir::Browser object with an open browser?

No, Watir/Selenium can not interact wtih browsers that were not started by a driver in the current coding session. You can do what you want by copying/pasting into the same irb session, or insert a sleep command to give you time to do the manual work in between the two different automated parts.

What are some good Ruby-based web crawlers?

I am building wombat, a Ruby DSL to crawl web pages and extract content. Check it out on github https://github.com/felipecsl/wombat

It is still in an early stage but is already functional with basic functionality. More stuff will be added really soon.

no such file to load -- ffi_c (LoadError)

I think the missing file relates to the FFI gem. I had issues trying to use FFI v1.0.10 myself (when it went to install, and due to something pertaining to webdriver code) so on my box I have v1.0.9 of that gem installed.

I'd say there's not much to lose by trying to roll that gem back a version. From the command line type

gem uninstall ffi

once it's done then

gem install ffi -v 1.0.9

See if that fixes things for you.

Update the FFI gem has since updated past 1.1.0 and these versions seem to work fine with watir and watir-webdriver, however the gem is not pre-compiled, and has to compile code when it installs. This means if you are running on a PC you will need to install the Ruby development kit for windows, aka 'devkit', you can get it from the downloads page on the rubyinstaller site

download and install devkit first, then open a new command line window and use

gem install ffi

to get the latest version of the FFI gem

if for some reason that does not work for you, you can always use the original instructions above to install the slightly older version of the FFI gem

Integrating Automated Web Testing Into Build Process

Phil,

Automation can just be hard to maintain, but the more you use your automation for deployment, the more you can leverage it for test setup (and vice versa).

Frankly, it's easier to evolve automation code, factoring it and refactoring it into specific, small units of functionality when using a build tool that isn't

just driving statically-compiled, pre-factored units of functionality, as is the case with NAnt and MSBuild. This is one of the reasons that many people who were relatively early users of toole like NAnt have moved off to Rake. The freedom to treat build code as any other code - to cotinually evolve its content and shape - is greater with Rake. You don't end up with the same stasis in automation artifacts as easily and as quickly with Rake, and it's a lot easier to script in Rake than NAnt or MSBuild.

So, some part of your struggle is inherently bound up in the tools. To keep your automation sensible and maintained, you should be wary of obstructions that static build tools like NAnt and MSBuild impose.

I would suggest that you not couple your test environment boot-strapping from assembly load. That's an inside-out coupling that only serves brief convenience. There's nothing wrong (and, likely everything right) with going to the command line and executing the build task that sets up the environment before running tests either from the IDE or from the command line, or from an interactive console, like the C# REPL from the Mono Project, or from IRB.

Test data setup is simply just a pain in the butt sometimes. It has to be done.

You're going to need a library that you can call to create and clean up database state. You can make those calls right from your test code, but I personally tend to avoid doing this because there is more than one good use of test data or sample data control code.

I drive all sample data control from HTTP. I write controllers with actions specifically for controlling sample data and issue GETs against those actions through Selenium. I use these to create and clean up data. I can compose GETs to these actions to create common scenarios of setup data, and I can pass specific values for data as request parameters (or form parameters if needs be).

I keep these controllers in an area that I usually call "test_support".

My automation for deploying the website does not deploy the test_support area or its routes and mapping. As part of my deployment verification automation, I make sure that the test_support code is not in the production app.

I also use the test_support code to automate control over the entire environment - replacing services with fakes, turning off subsystems to simulate failures and failovers, activating or deactivating authentication and access control for functional testing that isn't concerned with these facets, etc.

There's a great secondary value to controlling your web app's sample data or test data from the web: when demoing the app, or when doing exploratory testing, you can create the data scenarios you need just by issuing some gets against known (or guessable) urls in the test_support area. Really making a disciplined effort to stick to restful routes and resource-orientation here will really pay off.

There's a lot more to this functional automation (including test, deployment, demoing, etc) so the better designed these resources are, the better the time you'll have maintaining them over the long hall, and the more opportunities you'll find to leverage them in unforseen but beneficial ways.

For example, writing domain model code over the semantic model of your web pages will help create much more understandable test code and decrease the brittleness. If you do this well, you can use those same models with a variety of different drivers so that you can leverage them in stress tests and load tests as well as functional test as well as using them from the command line as exploratory tools. By the way, this kind of thing is easier to do when you're not bound to driver types as you are when you use a static language. There's a reason why many leading testing thinkers and doers work in Ruby, and why Watir is written in Ruby. Reuse, composition, and expressiveness is much easier to achieve in Ruby than C# test code. But that's another story.

Let's catch up sometime and talk more about the other 90% of this stuff :)

How to avoid StaleElementReferenceException in Selenium?

This can happen if a DOM operation happening on the page is temporarily causing the element to be inaccessible. To allow for those cases, you can try to access the element several times in a loop before finally throwing an exception.

Try this excellent solution from darrelgrainger.blogspot.com:

public boolean retryingFindClick(By by) {
    boolean result = false;
    int attempts = 0;
    while(attempts < 2) {
        try {
            driver.findElement(by).click();
            result = true;
            break;
        } catch(StaleElementException e) {
        }
        attempts++;
    }
    return result;
}