Oblomovka

2003-02-06»

Rafe asks about blogger’s test-driven development experiences. I’ve been messing around with XP on-and-off for the last month or two. Yoz and I are doing some long-distance pair programming via TightVNC, Leo, and Yahoo Messenger Voice Chat, which has been slow-going but fun. I haven’t used XP or unit-testing for large projects, but I’ve been thinking a lot about my experiences.

Unit testing is definitely the easiest part of XP to grasp, but the XPers have a point when they say that much of the benefit of writing tests before you code comes from synergies from XP’s other practices. One of the reasons why most of us don’t write as many tests as we should is because of the limited returns. You spend a long time writing little fragments of code, which only come into their own if a bad bug trips them up in a predictable way. Anyone who has got caught in the trap of writing test code to catch bugs, only to find themselves fixing bugs in the test code, knows that tests can be a real drag on the flow of programming.

Unit testing before you code ups that return on investment. Firstly, while you’re writing the test code, you’re also mentally fleshing out the interface and algorithms of the future class itself. Many times now, I’ve found myself wrestling – and solving – some of the biggest algorithmic problems I have to face in writing a method while I’m writing the early test code. This has a couple of effects: psychologically, coding up the tests seems much less of a waste of time. It feels like a useful warm-up to the final work, rather than a finickety post-facto dredge over your previous work.

More practically, it means that the final product itself is far less composed of the lumber of a a dozen experiments. The effectiveness of this is particularly true in XP’s iterative design process. There’s a minimal amount of upfront design in XP, but there’s design *somewhere*. One of the hidden places design gets done is throughout the testing process. Now, that may horrify you, but it definitely means there are rewards to writing tests first that may not exist in a less agile development environment.

It has another knock-on effect, which, I think, leads to more productive and pleasant testing. When I’m writing unit tests these days, I feel a strong pressure not to “code to the test”.

The initial temptation when first writing pre-code tests is to write the minimum needed for your code to work. For instance, the code we’re writing at the moment is a simple WAP client. We have a test which just “presses the button” on the WAP page, to see whether we’re actually activating a CGI script. Putting aside whether this is really a unit test or a functional test (I admit to not truly understanding the difference), our first bash at this had something along the lines of:

def testButtonPressable(self): full_url = self.wap_dir + self.formurl() # get url of form params = urllib.urlencode({'test' : 1}) # set form with "test=1" f = urllib.urlopen(full_url, params) # open the CGI script return self.assert_('<!-- TEST OK -->\n' in f.readlines())

1	def testButtonPressable(self):     full_url = self.wap_dir + self.formurl() # get url of form     params = urllib.urlencode({'test' : 1})  # set form with "test=1"     f = urllib.urlopen(full_url,  params)    # open the CGI script     return self.assert_('<!-- TEST OK -->\n' in f.readlines())

Yoz and I discussed this for quite a while. I felt uncomfortable. It seemed to me that the test added code to the final version, but the wrong sort of code. It just adds to the main method code which fulfills the test’s requirement, and little else.

I was a bit surprised by my reaction to this, but realised that it’s partly what XP teaches you: because you’re outlining the skeleton of your later design in your tests, code like this feels like wasted effort. The test sketches the outline of code, but it’s not code that’s a step toward your final end product.

In the end, Yoz won this argument, and did so by pointing out, I think, one of the problems of unit testing the XP way. XP emerges, in large part, from Smalltalk best practices. One of the great features of Smalltalk is that you’re working in a completely OOP environment. Access and introspection just aren’t much of a problem. If there’s an object out there, you can talk to it.

No matter how OOPified our current programming world is, that’s just not the case, and that poses problems for unit testing with suites like JUnit. Take a look at the example above. One way that we could improve the design of the code, and write a test that fits in with the main execution flow is something like this:

def testButtonPressable(self): full_url = self.wap_dir + self.formurl() params = urllib.urlencode({'test' : 1}) f = urllib.urlopen(full_url, params) cgiobject = CgiObjectSingleton() return self.assertEquals(cgiobject.form['test'], 1)

1	def testButtonPressable(self):     full_url = self.wap_dir + self.formurl()     params = urllib.urlencode({'test' : 1})     f = urllib.urlopen(full_url,  params)     cgiobject = CgiObjectSingleton()     return self.assertEquals(cgiobject.form['test'], 1)

Here we really are testing something, without adding additional code. We’re seeing if opening the form’s submit URL passes data to our cgi code. To do that we get hold of the object that represents the CGI codes state, and peer in it to see if it received the form data.

Unfortunately, this approach is impossible without quite a bit of wrapper coding: the CGI script in our world is in a completely different process space, and lives and dies without being easily introspected by our test code. We could write a persistent CgiObject communication interface, but you wouldn’t normally do so when writing CGI code without a unit test.

This seems a random example, but I’ve hit the same problem in other places as well. Testing WxPython GUIs using PyUnit is difficult, for instance, because somehow you’ve got to interpose your tests into your Python app’s event loop. I have funky code to do this now, but it required some heavy extra coding. Unless you’re really enthusiastic about writing your own test framework code, such test framework hacking has got to feel like wasted time.

It goes without saying that in Smalltalk you hit these problems far more rarely. You’re all sitting in the same event loop, and all instantiated objects and classes are accessible.

Even with these problems, though, I still write my tests before my code. Why? Well, part of the reason is I rather like Smalltalky OOP: having easily examined objects I think does lead to better code, and it’s nice to have that kind of architecture fall out of the test code you’re writing. One of the recurrent problems with CGI code, for instance, is that it’s really tempting to write it in a procedural style. Splitting it up into individual objects makes things a lot easy, and unit testing helps build that discipline.

The other reason is, as the phrase goes, I’ve become “Test Infected“. My tests have now caught so many bugs, small or large, that it feels rash to write code without writing the tests first.

My infection was unconnected to XP practices. The first program I wrote tests for was the code that handles my mail archiving. I really, really, really didn’t want this to fuck up, so I carefully pre-wrote all my tests. Since I started using the code (about 700 lines of Perl), I’ve only hit one bug. I found the problem almost instantly by kicking up the test suite again. It turned out that the syntax of the GNU ‘date’ command had changed subtly between versions. It’s the sort of bug that would have taken days to track down without the testsuites.

My own feeling is that, if you’re uncomfortable with JUnit, just write tests the way you feel comfortable with. After a while, when you’ve received some outright benefits from using tests, you’ll feel more encouraged to get to grips with a more alien suite. In the end, the *Unit classes are just a fancy way of saying: test this, then this, then this, then this. And that’s all you need. For small programs these days, I’m spending more time in Python’s doctest .

Comments Off on testiness

2003-02-04»

About seven months ago, I was gibbering in my Sunday Times column about Internet pressure groups. I rather glibly promised to give links to anyone who mailed me with info about their own single issue site. I’ve now dug up the mailbox that contained all of those URLs. Gritting my teeth with the shame of being so late, here are those links. No guarantee of quality here – they’re just people who wrote in. It’s spoor for the googlebot, mainly.

Somewhere to go if you’re a descendant of the Bond-Jones family of Liverpool.

A slightly strange free online test for heart trouble., together with a history of the Norfolk and Norwich hospital and the unsuccessful fight for its survival.

A kinda warbloggy, kinda not Irish blog.

A site by Brian Barder which, as he says, “absolutely buzzes with multiple bees from my pinkish bonnet”. It’s sort of JerryPournelle.com mixed with Samizdata.net in the style of David Brake’s Weblog. Also, possibly, Jimmy Young.

A site about looking after children’s teeth.

A parody of National Westminster bank.

A site that lets you add your own entry to the Band Family Tree.

And Greenhouse Gas News, which does exactly what it says.

Comments Off on bees in bonnets

I’ve had a rant building up about this for some time, but Stef’s always been better at the nuclear-tipped flame than me.

We’ve running FaxYourMp.com for two years now, always in the expectation that Parliament would eventually introduce their own system for making representatives more easy to contact. Not only has that not happened – they’ve now started filtering constituency mails. Their obscenity filter has caught constitutent mails about the upcoming Sexual Offences Act, and a party position paper on – of course – censorship.

Stef has all the facts on faxyourmp.com, and more. It’s really worth reading, both as an examination of where e-government is now, how far it has to go. And how easy it could be to get there.

One of the most heartening aspects of the service has been the letters that constituents write. Almost without exception, the letters they send MPs are reasoned, well thought out, not always perfectly spelled, but often insightful engagements in civic society. Far from the image of a disaffected and disengaged electorate, we see a mass of people who’ve discovered that they can effectively participate in democracy- if artificial and archaic barriers are not put in their way.

I can’t be the only one who sees the irony in the fact that in the week that we celebrate 50K faxes served, the people whose job should be doing what we do for free are still trying (feebly) to raise barriers against the citizenry.

There’s a dramatic mindset change that needs to happen over there, because, if you will not give us greater democracy, we will simply take it from you.

Comments Off on the story behind faxyourmp

2003-02-02»

Paul Ford quotes Ullman, on coders endlessly feeling their way forward:

The corollary of constant change is ignorance. This is not often talked about: we computer experts barely know what we’re doing. We’re good at fussing and figuring out. We function well in a sea of unknowns. Our experience has only prepared us to deal with confusion. A programmer who denies this is probably lying, or else densely unaware of himself.

Comments Off on recurse

The BBC News site has gathered together a panel of experts to answer questions on the Iraqi war. They’re answering queries that range from straightforward but rarely answered (“Why isn’t Saddam called ‘Mr Hussein’?“) to the slightly tougher (“Can NOT going to war be unethical?“, answered by Julian Baggini, humanist moral philosopher).

Comments Off on war, good for, what is?

2003-02-01»

Looks like WINE, the Windows non-emulator for Linux, is going to have some problems making the shift to glibc2.3. WINE has its own implementation of threads, which glibc doesn’t know about. Part of the act of splicing this implementation into the old glibc involved gently pursuading the library to look in a different location for system error result codes. That hack doesn’t work in the new glibc.

It looks like the solution may be to port WINE to libc threads, which is a bit terrifying. Previously, it’s been out of the question, because there just wasn’t a good match between pthreads system and the Windows model. A combination (I think) of the new kernel’s thread implementation and improvements in pthreads itself may fix that, but it’s still a big leap.

If WINE does make the move, a few other bonuses fall out of the work. Firstly, Mono, the Unix port of .NET, would be able to re-use WINE code for its graphics and UI libraries. And because WINE would no longer be bbolting strangeness onto glibc, the project would be able to use Valgrind, the open-source memory debugger for x86-Linux.

There are political ramifications also. The WINE project is in a curious configuration at the moment, with several groups keeping their own mildly forked versions (either for business reasons, or because of disagreements over licensing). They’re all going to have to come together to co-operate with this – and in pretty smart order, because Redhat ships with the new glibc in a few months.

These are the kind of shifts that often utterly devastate private programming projects. They can be pretty stressful for open source endeavours too. If you are at all curious how free software copes with major logistical challenges, this would be a good project to watch.

Comments Off on wine trouble

2003-01-31»

Phil “Samuel Pepys” Gyford has re-animated an old project of his, Byliner. It keeps track of online publications like Salon, the Guardian and the NYT, and mails you when new articles appear by your favourite authors. It’s a great resource – can’t wait for when Phil implements RSS feeds too. The Daypop stylee most popular stories and authors page is fun.

Comments Off on byliner is back

Looks like there’s a reasonable chance they would have been shredded, along with as many as 90,000 other applicants. As Robin says, how many of those INS detainees were held as a result of this, or some less deliberate bureaucratic foul-up?

Comments Off on phew, glad i didn’t manage to get my ins papers in

2003-01-27»

I’m forever getting half-way through what I think is one of Doc Searl’s posts, then abruptly realising that I’m actually reading Samuel Pepy’s Diary. “Met with Tom Newton, my old comrade, and took him to the Crown in the Palace”. Oh, oh, I think: he means this palace, not this palace.

Comments Off on the perils of rss readers:

The talk I gave at the SDForum meet has now been slotted into the archive. It’s an hour long. I wouldn’t bother listening if I were you – I can give you the juicy bit in a nutshell.

I spoke about the old idea that Europe is approximately 18 months behind the US in terms of PC and Internet tech. My position was that this was true from about 1994-2001, but that this was a temporary blip, spurred mostly by the geographical and cultural advantage the US had in Internet adoption. Here’s the really fun graph:

I stole most of the stats for this graph from this paper. As you can see, between 1984 and 1994, PC ownership as %age of the population in the UK was higher than the US. The US sneaked ahead during a burst of computer ownership in the late nineties (I think perhaps spurred by faster Net adoption), but since then the distance between the two curves has narrowed. Or at least, I think it has – I had to a bit of extrapolation for some of the points on that last bit of the curve.

Here’s the other graph, which shows the narrowing of the “18 month” gap between the UK and US a bit more clearly.

Comments Off on venting plasma