Version control your automated tests, quickly, easily, today for free

Why don’t testers version control their tests?

I am still surprised at how many organizations don’t version control their automated test scripts. I put it down to the following reasons:

  • Developers may use expensive version control tools, but sometimes there aren’t enough licenses for testers;
  • People don’t realize there are free version control tools available;
  • Setting up version control might be considered too difficult for the test team;
  • Some people believe you need to own a version control server to version your test scripts; or
  • Any combination of the above.

In reality:

  • If the software developers’ version control system is available for testers great, but if not, test scripts can be versioned separately;
  • There are many different free version control tools available. TortoiseSVN, which uses the Subversion (SVN) protocol, is very popular and very easy to use;
  • Setting up a new SVN repository using TortoiseSVN only takes a few minutes; and
  • You can set up a SVN repository on a shared network drive, so you don’t need a server (but a server is cool).

How to quickly set up a new SVN respository on a shared network drive (using Windows)

If you haven’t version controlled your test scripts yet, here’s how to do so.

  1. Download and install TortoiseSVN from (it’s about 19MB, and requires a reboot: bummer :( )
  2. Find a location on a shared network drive where you can store your SVN repository. For example, it could be Q:\SVN  Repositories , create a new directory for your repository (eg. Q:\SVN  Repositories\WatirMelon\ and right click within this new directory in Windows Explorer, and choose TortoiseSVN, and then ‘create repository here’. The path to your new directory will be your SVN repository path. Create SVN Repository Here
  3. The repository should be created in a matter of seconds, and filled with some directories and files. These files/directories should never be touched, under any circumstances. Repository created successfully
  4. Now you need to create a local repository and check out the new repository (which will be blank initially). Create a directory on your local drive for your repository, for example C:\watirmelon, and right click within this directory and choose ‘SVN Checkout’. SVN Checkout
  5. You will need to specify the location of your repository you created in Step 2, but importantly you will need to add file:/// to the front, and change the backslashes into forward slashes. Checkout Dialog
  6. Once you click OK you have a repository (albeit blank) checked out. You would then simply add all your automated test scripts, then do an ‘SVN Add’, and ‘SVN commit’. If you want to use your automated tests on another machine, you simply checkout the repository following steps 4 & 5 above.


So there it is. Now there’s really no excuse not to version control your automated tests, considering it’s free, quick, easy and doesn’t require a server. So go and do it now (if you haven’t already).

Australian Test Automation Workshop (TAW) 2009

TAW 2009 is coming up on August 27 & 28 and I have already confirmed my attendance (GTAC is a very long flight!) and created a LinkedIn event. TAW is held every year at Bond University on the Gold Coast in Australia.

I did a quick presentation last year, and I think I might do something a bit different this year.

You can download the presentation in full here.

My ANZTB SIGIST Watir Slides

It’s been a while since I presented at the Brisbane ANZTB SIGIST but here are my slides: note no bullets (as usual).

(it’s a shame you can’t embed Google Docs presentations here yet)

AWTA 2009 survey results

I conducted a survey for the Austin Workshop on Test Automation (AWTA) to see what people thought was good about the workshop and what could be improved in the future.  The response was very positive.

Whilst there were twenty-one questions, I believe the following two graphs tell the story:

How much fun did you have at AWTA 2009?
How much fun did you have at AWTA 2009?
Would you attend another AWTA?
Would you attend another AWTA?

The full results are available here. Bret also did a nice writeup of the AWTA 2009 proceedings here.

Easily define Watir tests in excel, OO, wikis and Google docs using Roo

I spent this evening playing with Roo, the ruby library for reading data from spreadsheets and I am very impressed. In a very small amount of time I was able to define tests in four different forms/places and could execute my tests from each of these:

  • An Excel file (.xls): stored locally
  • An OpenOffice (.ods): stored locally
  • An Excel file (.xls) stored in a Confluence wiki page with Confluence Office Connector; and
  • A Google Docs spreadsheet.

The great thing about Roo is that you don’t actually need Excel; Roo simply reads the file, unlike the ruby Excel COM WIN32 API I have used previously.

The spreadsheet (embedded in Confluence) looks like this:


The cool thing about embedding it in Confluence is that you can click the title of the spreadsheet to edit it (in OpenOffice in my case).

I made some minor changes to my existing code that executed my depot tests from a wiki page, and it was as easy as that. A data driven Watir solution with four possible ways to define test cases. Cool.

You can find all the code needed below.

require 'watir'
require 'rubygems'
require 'roo'
require './Customer.rb'
require './Common.rb'

case ARGV[0]
when "excel"
	ss ="watirmelon.xls")
when "wiki"
	ss ="http://localhost:8080/download/attachments/2097153/watirmelon.xls")
when "gdocs"
	ss ="")
	ss ="watirmelon.ods")

ss.default_sheet = ss.sheets.first
ss.first_row.upto(ss.last_row) do |line|
	if ss.cell(line,1).strip != "Function" then #We have an executable test
			module_name = ss.cell(line,1).strip
			method_name = ss.cell(line,2).downcase.strip.sub(' ','_') # automatically determine function name based upon method name.
			comments = ss.cell(line,3).strip
			expected_outcome = ss.cell(line,4).strip
			expected_error = ss.cell(line,5).strip
			required_module = Kernel.const_get(module_name)
			required_method = required_module.method(method_name)
			arity = required_method.arity() # this is how many arguments the method requires, it is negative if a 'catch all' is supplied.
			arity = ((arity * -1) - 1) if arity < 0
			parameters = []
			1.upto(arity) do |p|
			actual_outcome, actual_output =*parameters)
			# determine the result.
			if (expected_outcome = 'Success') and actual_outcome then
			    result = "PASS"
			elsif (expected_outcome = 'Error') and (not actual_outcome) and (expected_error = actual_output) then
			    result = "PASS"
			    result = "FAIL"
			puts "\nRunning Test: #{method_name} for #{module_name}."
			puts "Expected Outcome: #{expected_outcome}."
			puts "Expected Error: #{expected_error}."
			puts "Actual Outcome: #{actual_outcome}."
			puts "Actual Output: #{actual_output}."
			puts "RESULT: #{result}"
			puts "An error occurred: #{$!}"

See the full test code below the break.

Continue reading “Easily define Watir tests in excel, OO, wikis and Google docs using Roo”

Austin Workshop on Test Automation (AWTA) 2009

Watircraft are organising the Austin Workshop on Test Automation to be held on 16-18 January 2009 in Austin, Texas.

I have been approved to attend. It means three long flights from Australia (about 25 hours each way) but I am really looking forward to attending and meeting different people who are involved in Watir.

I haven’t been to America before either, so it should be really good.

Watir podcast eight

Episode eight of the Watir Podcast was released today in which Željko Filipin interviews me about my experience in using Watir, and also about my newly announced role as the Watir Wiki Master.

Check it out if you’re interested: