Expect’s a wonderful scripting language. Oh, it has its oddities, but I’ve been using it for over ten years now, and it’s proven useful in a variety of ways.

What is it? It’s a Unix based, fully featured scripting language based on Tcl that can take control of a user’s input and output and make decisions about what to do based on the results it gets. In other words, it’s designed to run programs that are meant to be run interactively by humans and put them under automated control.

Its uses aren’t unlimited: it’s definitely a command based scripting method — you’re not going to be controlling GUI windows with this. In checking around, there’s actually a few windows ports, but none of them really control windowed applications (one of them merely runs off cygwin!)

Where it shines is in automating tasks (especially of the system administration kind), and in testing (provided of course that no GUI is involved). I used dejagnu for years when I used to test network devices (routers, bridges, printservers, webcams, etc.

I can put together a script that checks for a new version of software, ftps it over, unpacks it, compiles it and then notifies me. I can then switch the current symlink to the latest version (or not) as I choose — all the grunt work is already done. I can do the same with any kind of repetitive task on unix.

I currently use it to automate the process of updating our services at work. Basically we offer a searchable database of texts, and we periodically upload new texts. The process involves quite a bit of “preprocess” — we go through the texts beforehand, find the words, and build several databases based on those words to help speed up the inquiries. We have searches based both on straight text search (slow, but can find substrings, etc) or a much faster word based search. The latter is accomplished through preprocessing. So first, we take the texts, and extract all the words. From this we can create indices based on unique instances of the words (678 occurrences of the word DOG in the database), or Btrees containing the complete location (filename and byte location) of every individual word. There are also databases recording the citations, others that help us create outlines for the material. You get the idea: lots of individual texts, many separate little programs to extract useful information, and all of it eventually welded together into a format usable by our website. Some of these tools are written in C. Others in perl, etc. We invoke the database command line to load things up. Files get copied over. Things get checked out, updated, committed from CVS.

Expect comes to the rescue here. It checks that we have the new set of texts, starts up each of the utility scripts in the correct order (checks that each completed without problems before advancing to the next). It also gives the user a number of options on how to do this: where the text files are located, whether we are on production or development machines, we can run parts of it (the prepatory work, versus actual loading of the data once preprocess complete). It handles safety stuff, such as dumping database schemas and cvs’ing them before dropping databases and resconstructing them or copying/tarballing files off before replacing them. All of the tools are under CVS control, and the script knows enough to check for any updates and recompile as needed before using the tools. If you completely forget to set the tools up, it knows how to cvs check out the entire thing from scratch. Depending on which machine we run this on, it can take up to 24 hours to complete.

I can start it up and walk away from it. It’s wonderful. My coworker still gets to do his stuff by hand cos he hasn’t taken the trouble to put together a script for his stuff…

Some useful links for more info:
http://en.wikipedia.org/wiki/Expect
http://expect.nist.gov/
Also, dejagnu: http://www.gnu.org/software/dejagnu/

When we think of “bugs” most of us think of bugs in the code. But there’s all kinds of bugs out there, and one of the ones that annoys me the most is bugs in documentation.

Bugs in documentation?

Yep. Badly documented, under documented, erroneously documented, misleadingly documented. All of these lead to a similar result: the person can’t use the software.

But that’s not a bug!

Sure it is. If you have an error in the software, the user can’t use it. If you have an error in the documentation, the user can’t use it.

I think developers and programmers tend to lose sight of this fact, because they are not only capable of tinkering under the hood, they are used to doing so, and like doing so. That’s partly why they are developers and coders in the first place.

And if their audience were likewise developers and coders, the documenation wouldn’t be an issue (well, theoretically; there are always killjoy developers and coders like myself who side with the users on this one). But the problem is the audience is generally a wide set of folks who not only can’t tinker around with things, they don’t want to. They don’t have the time for it, there are other much better things they can do. So they’ll drop it, move on to something else, or even worse, use a competitor’s product that is more intuitive and/or better documented.

Incomplete documentation is an obvious source of problems and occurs far too often (recall how Selenium fails to document exactly how to install it, and Clipmarks fails to note that their icons are in the custom toolbar in their “easy 1-2-3″ setup). Worse yet, if some feature is not properly documented, the user may never utilize the full power of the software, and perhaps move on to another that does have the feature, under the mistaken belief that it does not exist in the current software.

I’ve seen cases where documentation existed, but was not updated to reflect changes in the current version. At worst the documentation becomes incorrect, at best, misleading.

Sometimes documentation is just badly written. It needn’t be obvious. Consider a common example, in which each option and each command is separately listed and described. It’s complete, it covers all the possiblities, nothing has been left out…but the average user still can’t figure out how to make use of it. Why? Because the documentation fails to cover scenarios. If there aren’t sections explaining how to use the software for various different purposes, a user may still be completely lost if it isn’t clear what approach should be taken.

First of all I’m going to note that Selenium comes with an utter lack of documentation and what documentation does exist is utterly disorganized. This has proven to be the biggest stumbling block to actually getting started with Selenium.

It seems promising enough: It’s a java based testing tool that you install in your *nix setup alongside apache (definitely root access material here) and then there’s a firefox extension (what originally caught my attention in the first place) to help construct test cases through browser usage.

And certainly the few bits of documentation were all aglow! “Just unpack here, and VROOOM!!!” I mean, come on:

Selenium is a test tool for web applications. Selenium tests run directly in a browser, just as real users do. And they run in Internet Explorer, Mozilla and Firefox on Windows, Linux, and Macintosh. No other test tool covers such a wide array of platforms.

So, cross browser and multiplatform. I like this. Plus,

Selenium IDE is an integrated development environment for Selenium tests. It is implemented as a Firefox extension, and allows you to record, edit, and debug tests. Selenium IDE includes the entire Selenium Core, allowing you to easily and quickly record and play back tests in the actual environment that they will run.

I mean, I’m just rubbing my hands, here.

But what’s this? Trouble in paradise? If you look through all the selenium documentation, there is nothing that discusses how to install it. Finally, after quite a bit of hunting around, you can find this (note that it is NOT on any of the “official” pages but a separate blog ) –

For people new to Selenium, here’s a 30-second (32.78 seconds to be precise) tutorial on how to install Selenium on a Linux box running Apache. I’ll assume the DocumentRoot of the Apache installation is /var/www/html.

1. Download Selenium from openqa.org. The latest release of Selenium as of this writing is 0.6.
2. Unzip selenium-0.6.zip and cd into the selenium-0.6 directory.
3. Move or copy the selenium sub-directory somewhere under the DocumentRoot of your Apache server.

That’s it — you have a working Selenium installation!

Whoa nelly. Not quite. First, you do have to do some basic mods to httpd.conf for Apache. I added these items:

<Directory "/Web/selenium/">
    Options Indexes FollowSymLinks MultiViews ExecCGI
    AddHandler cgi-script .cgi .pl .js
    Order allow,deny
    Allow from <i>myhost.com</i>
&lt;/Directory&gt;
Alias /selenium/ &quot;/Web/selenium/&quot;
 


Then after unpacking the zip archive into the selenium directory, I go over to the new website and get…nothing. The test cases don’t respond to anything. This is on a sun solaris; I’m reasonably sure that Java and JavaScript are running okay. And in fact, I can run their TestRunner demo which is hiding somewhere over the selenium site; I forgot to mark it and haven’t quite got the energy to hunt it down here at home. But I ruled out something not being set up on our end, otherwise it would not have run at either location (mine and theirs).

And then I discovered this little gem that recommended modifying selenium-api.js in the directory. Oh. Dear.

Well, I took a deep breath and made the modifications, commenting all over the place so I’d be able to figure out what I’d done later. Bupkus.

So there it remains at the moment until I get a chance to get back to it. Hasn’t been too much extra time at work lately, though.