Thoughts on test driven development

At the start of May. Simon and I redid the database layout for Sutekh, and, since then, have been working on fixing all the fallout of that. I recently spent a bunch of time working on finishing off some parts of the transition. Since we had a good idea of what the code should accomplish, I ended up doing most of this in a very test-driven fashion. Since most of my work is much more experimental in flavour, and doesn't thus doesn't lend itself to strongly test-driven development, it was an interesting exercise.

Some observations

1. Having the test available is nice, especially given the number of interactions involved
   
2. It tended to get sucked into "let just get this test working", and, as a result, the first version that successfully passed all the tests is a poster case for the difference between "working code" and "decent code". I'm still busy refactoring the code to amalgamate common bits, and there's still considerable work before the code is maintainable.
3. I frequently erred towards being overly concerned with not breaking the tests. I ended up duplicating code unnecessarily in places as a result.
   
4. Refactoring is made easier by the test, though.
5. Largely as a result of 2, I don't actually have that good a mental map of the code, which feels rather weird. Spotting repetitions between the different code paths is thus quite time consuming.
6. I do have quite a lot of confidence in the tests.

A fair bit of this list boils down differences in the manner in which code is produced. In my usual development model, by the time I'm satisfied that the code is doing what it should, I've spent a lot of time worrying about specific details and all sorts of implementation issues, and consequently, the code is vastly more polished. Here, because I was usually focused on short term gains, I have something which does what I want, but still needs considerable work before I'll regard it as complete. Also, as the list illustrates, I made the error of treating this as a bug-fixing exercise, rather than as development, so that's something I'll have to bear in mind in future. Point 5, though, is the real problem, though, and I'm not quite sure how to fix that, although things should hopefully be a lot better by the time I finish refactoring.

Still, despite my complaints about the resulting code, it did make the development a lot easier, and, for a part-time project, being able to deal with it in the smallish chunks of "let's get this test case working" did make it much easier to maintain momentum via visible results.