At my office we do a lot of functional testing – interacting with our software as an end user would. This, in itself, is enough of a problem: much of what we do would be better tested with unit tests or automated functional tests (see Selenium for example). But it’s hard to retrofit comprehensive unit tests into a large, established code base (that wasn’t created with unit testing in mind) and it takes time to convert from written functional tests to automated functional tests. With all the test writing, editing and performing I’ve done, I have a few notes on what you should (and should not) do with your written functional tests.

Please, for your sanity, use a text based file format for your tests. If you don’t, version control (CVS, Subversion, etc.) won’t work for your tests. It’s a good thing to be able to see what changed between revisions of a test and you simply can’t do that if your version control system can’t do a meaningful diff of two versions of a file. Even more importantly, if you use a text based file format, your version control software can merge differences when you update your working copy. With a binary format, only one person can edit a file at once. This means no Word tests!

Use a source format that uses cross referencing and handles (nested) lists automatically. I like LaTeX, but as long as the software takes care of lists and cross referencing for you, you’ll be happy. I’ve spent a lot of time renumbering tests and updating references; it just isn’t a sensible use of anyone’s time.

Make your tests compartmentalized. It’s OK to have a set of setup steps for a set of tests, but if a test changes anything so that it’s different from that base line it should change things back when it’s done. It might take a little longer to run a test that cleans up properly but there is no reason that you should have to track down what the test you ran half an hour ago did to sabotage the test you’re running now.

Ultimately, don’t depend too much on human executed functional testing. It’s useful for end-user facing interfaces but it is too prone to human error to use on a very large scale. Automated tests and unit tests – those where the instructions can’t be misread or steps can’t be forgotten – are easier to maintain, faster and, because of their speed, can be run more often (which will shorten your development cycle and catch bugs sooner rather than later).

I’m playing with http-access2, a Ruby library for programatically accessing web pages. I want to write a web app that sits between people and a privileged admin interface and this seems like it will do the trick. It’s a little slow but I think that’s the SSL talking.

Cross posted from Today in Brief.

Ars Technica has a chilling summary of the current problems with electronic voting.

As the article states, even if we assume there is no willful tampering being done with these electronic voting machines, we’re in for a terribly shitty midterm election in those states/precincts using the machines. Poll workers are poorly trained, procedures for making sure the correct votes are recorded and counted are not in place, the machines can easily and undetectably tampered with, there is no dependable audit trail.

Electronic voting is not a panacea for the problems we saw in 2000. Voting problems are addressed with procedure, including auditing (paper trails) and vote verification (preferably at the polling place AND after you’ve gone home). As we see in too many places these days the focus of current voting system work is on presenting a facade to make it appear that our votes are secure and will be counted correctly. Unfortunately it seems that, in many places, that facade will break down when it is least convenient for the electorate.

A side note: the eminent cryptographer Ron Rivest proposed a damned good verifiable voting system, the best part of which is that it uses no fancy math and no computers to cast the votes. Read the paper, as much as you can, it’s an incredibly simple scheme that would work very well.

Here’s a reminder to myself to check out The Battle for Wesnoth when I get home. That’s all.

I’ve commenced cleaning house and moving everything to the goterkyourself.com domain … both http://rain.xidus.net and http://cs-people.bu.edu/jterk – the two other locations I had on the web – now redirect to http://goterkyourself.com.

It’s a small change, for now, and a bunch of old stuff (from rain.xidus.net primarily) is now “missing.” But I have it saved and, in the coming {days,weeks,months} I’ll move it all to goterkyourself.com (and the various sub domains) and, hopefully, setup permanent redirects from the places they used to be.

I added a rudimentary commenting system to GTY today. If you navigate to the page for an individual entry (by clicking on the entry title) you will be greeted with a comment form on the bottom of the page. Your comment will not appear immediately but don’t despair! The form sends me an e-mail for each comment and I have to manually add that to the blog. This is the easiest way for me to implement comments and it will help avoid a deluge of comment spam … at least for you, my faithful reader; I’m sure my inbox will promptly fill up with advertisements for v14gr4.

Edit: I’ve switched to Typo, which does comments in the normal fashion, obsoleting this post. Hooray!

As is apparent if you read any of my older posts, which you surely haven’t, I have a motorcycle. It’s a 1978 BMW, so it’s in need of periodic maintenance and repair. Thankfully there’s a wonderful resource – the Airheads Beemer Club – which, along with the airheads mailing list, provides a vast amount of advice and instruction from many people who have more knowledge of these machines than anyone else who does not work for BMW (and perhaps more than most who do).

The current form of knowledge distribution, as it were, is a monthly mailing called Airmail, which contains riding stories, upcoming events, classifieds and the technical advice of Oak Okleshen. For many, Oak’s tech articles are the reason for Airmail and for paying the yearly dues (a piddling $20) for the club.

Recently, on the airheads mailing list, which is disconnected from the club (one need not be a member of the club to join the list, nor do members of the club need to subscribe to the list), talk of a Wiki has come up. The reactions to the suggestions have been interesting and varied. The most vocal responses, surprisingly (to me), have been negative. The amount of opposition to the free editing and self policing nature of a wiki is counter to my experience – Wikipedia is a great resource for all sorts of topics and, for those that aren’t covered well, one can always add to or modify the topics to improve them.

There’s a lot of worry about theft of intellectual property and the presentation of someone else’s materials as one’s own. These worries are groundless; the versioned nature of a Wiki and the ability to track all changes, along with (at least on a Mediawiki powered site) the ease of discussing changes in an article, mean that it is extremely difficult to pass another’s work off as original. Someone familiar with the original work is bound to come along and call the plagiarist out.

I’ve been keeping my own opinion off the list; I don’t see a reason to muddy the waters further and, if a Wiki is a good thing for the club, it will succeed despite the efforts of those who might actively oppose it. Give the Airheads Wiki a look and, if you have anything to add, feel free to contribute.

A while back Amazon released their S3 service to provide unlimited, reasonably priced, on demand web services based storage space. At $0.15 per GB space used and $0.20 per GB transferred (both per month) it’s rather a good deal.

JungleDisk claims to provide a DAV interface to an S3 account for Windows, Linux and Mac OS X. I’m contemplating giving it a go, just to see what it’s like. It would certainly make a nice off-site backup solution, if it isn’t too expensive. I’m pretty sure that it’s cheaper than co-location, although a little bit limited in scope (relatively speaking).

It’s so hard to post regularly. Let’s sing a song about waitin for Amazon to let me pay them lots of money for EC2:

La La La! Waiting for EC2! La La La! I’m way lamer than you! La La La. Please don’t hit me with your shoe! La La La! I want to spend all my money on EC2!

Thank you, I’ll be here all week.

In regards to the previous post, where I mentioned being able to edit regions of a Hobix post with different modes, MMM Mode looks very promising. More to come.