Test-Driving Web sites

Scratching an itch

As you might have gathered visiting this site, I am currently reorienting my career plans to become a freelance consultant. (My reasoning is that all employers stink, so I might as well pick the worst possible one and become self-employed; ha-ha only serious.)

So naturally I've hung out my virtual shingle at http://bossavit.com - and naturally, the minute this got beyond one text page and no images, I started making mistakes. Just small stuff - broken image links, things like that - but it got me thinking. (While I was thinking, I installed a CVS server on my site, almost reflexively. Some things you do because they're philosophically compelling, like test-driven development. Some things you do because they're just basic survival habits.)

Programming without tests makes me nervous. It's only normal that creating interactive content - half text and half programming - should also make me nervous. Nowadays I get nervous when I write an article or an email and don't have a "test" in head, too - but so far there isn't an automated solution to that problem.

Testing for standards

On the other hand, as far as a Website is concerned, there's lots of stuff that came to my mind in the way of automated tests. I started with the HTML itself. The W3 generously provides a nice battery of automated tests, so the simplest thing, before even rolling my own, was to check those out.

To make things even simpler for myself, I opted for the strictest possible level of quality - XHTML 1.1. The W3 validator duly proceeded to tell me about all of the bad HTML coding habits I'd acquired in my past life as a Web person: using tables for layout, meaningless images - i.e. those without an ALT tag, and a bunch of other things that are simply "not done" any more.

Fortunately, there turns out to be a simple, effective and standards-compliant way of doing the same things, which involves something called CSS. So I cheerfully dove into CSS, learned a whole bunch of new tricks, proceeded to recreate my initial design in CSS, and was bowled over by how simple and effective it turns out to be.

Hardly one hour into this test-driven Web experiment thingie and I was already : having fun; learning stuff; and churning out quality goods. Getting back into test-driven mode felt like coming home. (In fact, test-driven feels so good, telling about it makes me feel like a pusher. Go on, try it just once. You can quit afterwards, cross my heart and hope to die.)

Second gear

At this point I was thinking that I'd been only test-driving the design, not anything remotely deserving of the label "content". Also, I took a step back from the technique itself - however good it felt like - to get a larger picture of where I was going with all this. What was the point already ?

My Web site is the face I show to the world. Its audience is a triad : friends, colleagues, clients; these categories are dynamic and fluid, a given person can belong to more than one over time, and even in a short period of time someone could be looking at the site in more than one capacity. So the site has to reflect who I am as a person, the communities of practice I identify with, and the value I purport to offer as a professional. And it has to be nimble, to adapt itself to its audience.

This defined an overarching class of goals, to which I added a Metaphor elaborated previously : the worker bee, my ideal image of myself as a consultant - cross-pollinating ideas among a multitude of projects I would visit and building up a store of sweet programming wisdom.

This, too, characterizes test-driven development for me : the constant interaction between bottom-up pressures, low-level goals and urges such as "I'm having fun writing bits of content here and here, it makes me nervous, let's look into CSS" coalescing into a larger, coherent picture which imposes its own top-down dictates : "how does this fit into my career plans and life plans as a whole, what is the overall architecture to all this".

So back I descended into nitty-gritty technical detail, to bask one more in the sheer pleasure of doing things in as tiny steps as I needed to. My strongest Web programming language is PHP, and I was already pushing the envelope on one front (test-driving content- oriented Web development), so I prudently stayed with that and installed PHPUnit. I also had to come up with some form of "user story", a feature requirement small enough to do in a controlled amount of time, large enough to contribute to my overarching goals.

Going international, test-first

I picked one which reflects the international nature of the community, and - dare I say it - the current laggardness of my own country as far as innovations such as XP and agile processes are concerned : make content available in the language most appropriate for the user.

In the middle of a project, I would want to start with a "customer test", a bigger test written from the end-user point of view. However, this usually implies some infrastructure, infrastructure which is generally much heavier than the simple testing framework with which I will normally start a project. Web development turns out to be no exception; as well, the "bilingual site" story is one which I'm confident enough of implementing correctly, so I felt I could move to implementation details directly. While this can easily turn out to be overconfidence, and usually does, I'm not afraid of making a mistake, either.

Naturally, some things did turn out to be harder to test than they ought to be, as always for silly reasons. For instance, there's the usual problem of manipulating cookies in PHP, where for technical reasons you can't just say "I set a cookie", you have to do it at the start of a page, before outputting even one character of actual Web content. And I remember, the first time I ran into this problem I tore half my hair out in frustration. But now, instead of piling workaround on top of workaround until I finally hit on something that works, I could just encapsulate the nasty part in a little class, and test that the rest of it worked.

So far things are proceeding smoothly; in just 8 tests I've been able to implement a little "language switch" tool to my satisfaction. True to the vision of the Web site as a reflection of who I am and what I do, I've also put up a link to both of my test suites on the site itself : the W3 tests as well as my own tests.

Now what ?

Well, I'm thinking that now it's your turn. I realized upon writing this that there's a lot more I could do to further "open up" the process to inspection - make the source code for the tests and for the site visible; or put up a Wiki to gather "user stories" from visitors; or custom-code some sort of feedback form. Of course the design also needs a lot more work, and naturally I have to put up some actual content at some point, such as this article. Once I have content up there, or preparatory to that, I need to work out the navigation...

Well, you get the point. There's an infinity of "things to do next". What really matters is that I'm no longer feeling nervous about just doing whatever seems important for whatever reason, be it feedback from my visitors or my taking a fancy to something. I no longer feel like I should be working out an elaborate URL scheme or looking for a CMS package.