The Continuous Integration and Testing Conference is coming to Texas! The folks doing this conference (Paul Julius of Thoughtworks and Jeffrey Frederick of Agitar) have done 2 of these before, and all the reports I have heard have been good. I just registered, although it means that I will be out of town, away from family, and doing "work-related stuff" on the day before my 40th birthday!

• What: OpenSpace event discussing all aspects of CI and Testing, together
• Where: American Airlines Training & Conference Center, Fort Worth, Texas
• When: Friday and Saturday, April 27 & 28, 2007
• Who: Everyone interested in CI and Testing
• Cost: Free

Click the link above for all the details and to register. Limited to the first 100 folks, so get going!

---

Update

Argh!!!! I looked at my calendar and it turns out I will not be able to go to this after all. Hopefully someone else from DrillingInfo will be able to go.

Something I needed to know the other day, setting up the screensaver on my electronic photo frame (it runs Windows). The Old New Thing : The .Default user is not the default user

I got an actual test plan for a new feature today - a list of manual test steps. I've been wanting to try out WATIR (Web Application Testing In Ruby) after learning about it from one of its creators, Bret Pettichord, who I had the pleasure of working with at DataCert. This seemed like the perfect chance to do something fun and useful. 

I started by getting confused. I googled "WATIR" and got a couple of links on the first page - one to wtr.rubyforge.org that looked promising, but also a link to openqa.org. After poking around a bit on both sites, I figured out that the current stable production version (and previous versions) are on rubyforge, but the team is moving things over to openqa.

I decided I wanted to start with the stable version of WATIR for now (1.4.1), so from the homepage at OpenQA, I first linked to the ruby installer - some difficulty there, as I got the most recent version (1.8.5-24), but later discovered that the 'modal dialog' functionality in Watir is only supported in an older version (1.8.2-15 is what I ended up installing). The next slightly confusing thing is that there are a couple of ways to install watir. There is an installer, or you can install it as a Ruby 'gem'. The main difference in 1.4.1 is that the installer creates some start menu shortcuts and includes some examples and unit tests. The gem install is pretty much just the core functionality. I went with the 1.4.1 installer at RubyForge.

After getting all that set up, I finally got to start playing with it. I started by just running the watir unit tests. I installed to c:\watir, so just doing start->run and typing in c:\Watir\unittests\all_tests.rb made it start going. When I first did this I discovered the issue with the modal dialogs - there is a test for that, and when it gets to that point a dialog pops up asking you to press OK. You can press OK manually, but after that the test just hangs and you have to use Process Explorer or Task Manager to kill the wayward ruby processes. There is also another issue with the 1.4.1 install - it doesn't copy some of the images used in the html of the tests, so there are some breakages there. I checked out the watir source from subversion (https://svn.openqa.org/svn/watir/trunk/) and then copied the images from there to my watir installation. Some of the docs at the new OpenQA site indicate that the dev team is working on the packaging in the 1.5 version.

Going back to Ruby 1.8.2-15 was supposed to have fixed the problem with the modal dialogs, but so far I haven't been able to get the unit tests to run all the way through. In any case, it is fun to watch them all run!

Next step was to go through the a tutorial I found at http://wtr.rubyforge.org/s101/doc/. I went through several steps, trying out watir interactively using irb. That is pretty cool. Definitely print out the Ruby Cheat Sheet and the Watir Cheat Sheet to help with that. While that is fun, and will probably be a powerful tool in the future, I wanted to be able to move a little faster. A bit more googling led me to some posts by Scott Hanselman about his 'WatirMaker', which has since evolved into a whole watir-recorder project at OpenQA. There are a couple versions of recorders there - WatirRecoirder C#, WatinRecorder C#, and a ruby version. Getting a pre-compiled binary wasn't working for me, so I just checked out the source and ran the ruby version. I wrapped it in a little batch file to redirect the output to a file, and made a small change to the recorder to have all the "puts" calls go through a new method 'record' that did a puts to both $stdout and $stderr so that I could redirect to a file AND see what it was doing. Hacky, I know.

You will probably also want to sign up for the wtr-general mailing list to get your questions answered.

So here is the step-by-step:

1. Install Ruby 1.8.2-15 from RubyForge
2. Install Watir 1.4.1 using the installer (Also on RubyForge)
3. get the watir recorder from OpenQA
   http://svn.openqa.org/svn/watir-recorder/trunk
4. Write and/or record tests!

So far, I am pretty excited about this. I've shown it to several people in my company, and that excitement is spreading. I even showed it to one of our internal users, and suggested that they might be able to use the recorder to document bugs - wouldn't that be cool? We still have a long way to go - coming up with a way to structure the tests, integrate them into our build system, and (if we record tests) refactoring the tests to start creating a library of common functions that could be re-used across tests - but it looks like a good start.

Here is the batch file I used to wrap WatirMaker.rb, which I got from https://svn.openqa.org/svn/watir-recorder/trunk/Ru...

@echo off
if .%1.==.. goto :GET_NAME
set TestName=%1
if exist %TestName% echo That test already exists & goto :EOF
goto :RECORD_TEST

:GET_NAME
set /p TestName=Please enter the name of the test:

:RECORD_TEST
title Recording %TestName%
ruby WatirMaker.rb > %TestName%


If you do a search/replace in WatirMaker.rb and replace "puts" with "record" and then add the method below, it will work for you like it did for me. Next thing is to have it take a command line argument that is the name of the file so that ruby itself can write to the file rather than using shell redirection.

##//////////////////////////////////////////
##
## send the output to stdout and to stderr,
## to allow the script to show the recording
## as it is happening as well as to a file.
##
##//////////////////////////////////////////
def record(message)
$stdout.puts message
$stderr.puts message
end

I have written before about using subversion to provide source control for FitNesse tests, but we eventually abandoned that process because of difficulties with using the refactoring support built into FitNesse. We moved to a system where all edits to test pages were made on the shared FitNesse server, and if a developer needed to get those to their machine, they would use the wiki import feature. The problem was that we lost version control of the tests. Mike Roberts has also written about a system that is a little closer to what Jeffrey and I did.  

Here is another suggestion from Andrew McDonagh that was posted to the FitNesse users list. I've formatted his email and removed some of the location details.

We have always checked our FitNesse pages into source control....

This is how we do it....

The Shared Server
The FitNesse server for testing <our app> currently runs on http:/some.server. This server is a read only server and the wiki pages should not be updated here. The Acceptance Test pages on this server are automatically updated every few minutes from subversion.

Editing the FitNesse Wiki Pages
If you wish to edit the Acceptance Test pages, you need to install FitNesse locally on your machine. Please see the <our app> FitNesse Install instructions on how to do this (basically we have version controlled the download from fitnesse.org).

Setup
The next step will be to get the AcceptanceTest directory from subversion onto your local machine. To do this, use svn checkout from <subversion URL> to S:\AcceptanceTest. Under this directory is a file and a folder that are used for editing these pages.

S:\AcceptanceTest\FitServer.bat - this is a batch file that will start the fit server on your machine.
S:\AcceptanceTest\FitNesseRoot - this is the directory that contains all the files for the wiki pages.
Start the FitNesse server on your own machine by running the FitServer.bat file.

Local edits
To edit the pages on your machine, please use the fitnesse wiki interface provided. Connect to your machine and make the relevant changes. After you have finished your changes, and you will need to commit the changes for them to be visible to other users.

Saving changes back to the repository
Using TortoiseSVN, right-click on the S:\AcceptanceTest\FitNesseRoot directory and select SVN Commit. You will be presented with a log message window. In the bottom half of this window, there will be a list of 'unversioned' files. You need to right-click add these directories and files except for *.zip files. The ZIP files are the incremental revisions that the Wiki (it's own internal revision control system). For these ZIP files, after you have added the directory that they live in, you can use svn ignore to hide these files (right-click->TortoiseSVN->add to ignore list).

Running Tests-The Official Way
If you want to run the current suite of tests, please use the shared server.

As with our system, this will also have difficulties when you use the wiki refactoring tools (which are great to have). In this case, however, since each developer/tester is doing subversion commits manually (rather than the automatic commits on the server that we were doing in our system), people can note that certain files are missing and mark them as deleted in subversion, and add the new files as if they were brand new. Sounds like a pretty good setup.