Last week I looked into automating web-based user interface tests using Selenium Remote Control. This is a Java based server that listens for HTTP requests containing test commands. These commands are used to drive a web browser with a Javascript adapter. It works with IE, Firefox, or Safari depending on which operating system the Remote Control server is running on.

It was very easy to setup, download the Selenium Remote Control  java code. On Linux you can just type "java -jar selenium-server.jar" and the server starts up, waiting for commands on an HTTP server listening on port 4444.

As a quick test I started up tclsh

<pre>

 tclsh

% source selenium.tcl
% Se start
f6365af82d894c0ebd5d880484de2823
% Se open http://dave.thedesignexperience.org:8000
% Se assertTitle "Main Site"
% Se assertTitle "Wrong"

ERROR: Actual value 'Main Site' did not match 'Wrong'
</pre>

So this is interesting, it is really easy to start using Selenium RC from Tcl. One issue is that any false response to "assertTitle" will result in an error. So you need to wrap all the calls to Se with a catch so your entire test code can run.

My next step was to integrate this into the automated testing framework included in OpenACS. I added an init_class to start up the Selenium RC session at the beginning of a test run. This way all test cases that require Selenium will  reuse the existing session.  This works well. This pattern of test code seems to be easy to use within the acs-automated-testing environment.

<pre>
aa_false "Test Description" [catch {Se assertTitle "Main Title"} errmsg]
aa_log $errmsg 
</pre>

The aa_log of the errmsg is optional, but it helps with debugging.

Finally I decided that writing test be hand was not so much fun, and leaves out a large number of people from contributing to the testing effort. Using Selenium-IDE i created a Tcl-RC based format so tests can be recorded in a browser and the test code can be added to the test scripts in OpenACS.

The code is available in OpenACS CVS