Since I have some free time, I’ve been catching up on some of the stuff
\nI’ve been meaning to read. I’ve got a reading list of stuff that I’ve wanted
\nto look at that were written by other authors with my publisher. Yesterday, I started looking at Cucumber, which is an interesting behavior-driven development tool. This post isn’t really about Cucumber, but about something that Cucumber reminded me of.<\/p>\n
When a competent programmer builds software, they write tests. That’s just A test is an executable specification. Specifications are a really<\/em> good thing; executable specifications are even better. <\/p>\n <\/p>\n In general, in software, we have a tendency to think that we can do things by the seat of our pants. In my experience, most<\/em> programmers don’t do much planning before they sit down and start coding. In their heads, they think that they know what they’re building – they’ve got a model of the system, and how they’re going to put it together. But a model like that, which has never been written down, is quite like to have holes in it – because until you work through the details, you don’t necessarily even know<\/em> where the hard parts are.<\/p>\n Let me give you an example. A while back, when I worked for IBM, I was When you do versioning of directories, merging directories gets pretty complicated. To give you a sense, here’s some of the cases. Suppose you have a directory D containing a file F, and you’re merging two branches:<\/p>\n There are a bunch more cases – in fact, there are a total of 12 cases.<\/p>\n We built the first version of the system, and thought we’d worked out how to merge directory changes. People started using it, and found a case we’d missed, which caused Stellation to do the wrong thing. I worked out the problem, and fixed it, and released a new version. And another bug report came in – another case I’d missed. And another. And another. Directory merging was just a whole lot harder than I’d expected. <\/p>\n
\na given. But why do we do it? It seems like the answer is obvious: to make sure that our software works. But I’d argue that there’s another reason, which in the long run is as important as the functional one. It’s to describe what the software does<\/em>. A well-written test doesn’t just make sure that the software does the right thing – it tells other programmers what the code is supposed to do<\/em>.<\/p>\n
\nworking on an open-source SCM (aka “version control”) system called
\n“Stellation”. In Stellation, we tracked the version history of all of the artifacts that made up a system: we didn’t just version text files, but directories, binaries, etc. And we supported lightweight branches and (of course) branch\/change merging.<\/p>\n\n