My first attempt involved stubbing out HTTP calls using my mocking framework of choice. I'm using RestClient, which I like a lot, and stubbing out RestClient API calls worked quite well. It kept on working quite well for several hours, until I decided to refactor a little, using RestClient in a slightly differently way, at which point it broke completely. Bother. I really don't like having tests coupled to implementation details, so went searching for another way.

FakeWeb looked pretty good, in that it stubs things out at the Net::HTTP layer, which I'm unlikely to refactor out of the picture. In the end, though, it's not really what I wanted. I wanted to be able to do things like:

• verify the body (and mime-type) of a POST/PUT request
• dynamically generate responses, based on some aspect of the request (e.g. query parameters)

In short, I wanted a Fake Object, rather than a simple stub.

It occurred to me around about then that we already have plenty of tools for describing the behaviour of web-applications: they're called web-application frameworks! Many of them are too heavy-weight for my purposes, but Sinatra is nicely minimal. So, 60 lines of Ruby code later, I had a little web-app that mimicked one of those external web-services sufficiently for my testing. Win!

But waitaminut. I really don't want to have to start a separate process running my fake web-service, and talk to it using HTTP. That's going to be slow: network I/O isn't cheap. Isn't there some way I can use something like Sinatra but still keep everything in-process?

There is now. ShamRack plumbs Net::HTTP directly into applications built to run on Rack. Which includes all Sinatra apps, as well as Rails, Merb, etc.

Using ShamRack, I avoid the network traffic, making the tests a whole lot faster (about 25 times faster, in my case). Plus, I avoid the complication of having to start and stop an external web-server. Finally, because my fake web-service app is in-process, I get a handy back-channel I can use to setup or inspect it's state during tests.

If you find ShamRack handy, or have ideas about how it could improve, let me know!

Highlights include:

• a "multiWindow" option which places the application-under-test in a separate window, allowing testing of "frame-busting" apps;
• more reliable page-load detection for popup windows;
• new cookie-management actions;
• a run-speed slider and "Pause" button which replace the old Run/Walk/Step radio-buttons;
• many bug-fixes and stability improvements;
• tested against latest versions of Firefox, IE6, Opera, Konqueror, Safari and WebKit.

The multi-window layout option is a great step forward, since it was a limitation that prevented many people from using Selenium.

You can download the new version at:

http://release.openqa.org/selenium-core/0.8.0/

(Yes, the documentation and website still suck. Sorry.)

Now, I'm sure there are many great things about ClearCase. Not that any spring to mind. (Wait, here's one: it keeps ClearCase administrators in a job! Whew, I knew there had to be a silver lining somewhere.)

What I can tell you, though, is that it sucks for agile, team development. So, I've wrapped a script around the ClearCase command-line, to make the wannabe Subversion user in me feel more at home.

(Ruby: the glue that doesn't set).

The result is BasketCase (at RubyForge). It's still very much a work-in-progress (and when I no longer have need of it, will likely become a work-in-abandonment), but I hope it may provide a glimmer of hope to anyone else who finds themselves in a similar predicament.

By the way, the less observant of you may not have noticed that the name is a clever play on the word "rational". Geddit? Oh, nevermind ...

Digging into it, it looks like I've hit the Magik Creeping Text bug. Removing the border-left on the blog-entries fixed it.

Phew ... lucky no-one reads this stuff!

PragDave makes a valid point: categorisation is kind of artificial and arbitrary, and may be prone to change. Actually, even with only a handful of articles here on DogBiscuit, I've already been tempted to re-categorise :-)

The RubLog feature works by allowing links using just the last part (the "basename") of the article ID. If the same basename is used in multiple categories, this may result in collisions ... RubLog solves the problem by presenting all the matching articles. One problem here is that the user has no way of knowing which article is the "right one", ie. the intended destination of the link.

Categories as meta-data?

Another approach might be to capture categories in article meta-data, rather than using the file-system structure, e.g.

    Subject: Dealing with Recategorisation
    Category: /Tech/Projects/Eyaw
    
    A new feature ...

This way, articles can be filed into a directory structure that stays fairly constant (e.g. directory per day?), and so can be used to form "permanent" links. Categories are laid "on top", and it could even allow for an articles to be cross-filed in multiple categories. Holy dueling taxonomies!

On the downside, it becomes harder to see the category hierarchy, and modifying it potentially involves editing a whole bunch of files. Bother.

Basic features I'm after include:

• Wiki-esque markup
• Easy hyperlinking
• A simple, file-based data-store
• Easy navigation

But rather perversely, I'm not prepared to trust file mtimes to specify posting dates. Instead, I'm going to pull meta-information from the file "header". Sample input looks something like this:

    Subject: entry title
    Date: 13 Apr 2003, 11pm

    Here's the content ...