sfmagic.org Rewrite: Considering Unit Testing
I didn’t have time to get stuck into head-to-head today. Instead I did the minor data cleaning and code tweaking required to generate the superset, or block, standings. While doing that I started thinking about unit testing for sfmagic.org.
I’ve always liked the sound of test-driven development, and the concept of having tests in place after a section of an application is done (thus providingthe opssibility of getting some warning if you break that part later) definitely appeals to me—I sometimes have an unhealthy aversion to tinkering with working code on the grounds that I might break it, and easily-run, integrated tests would alleviate a lot of that worry.
Pylons, using Paste, has available a test framework package called nose. This looks pretty good, and I found a good introduction to it.
I commented last month that one of the most frustrating things about programming is all of the stuff you have to do before you get to the actual programming part. That is, all the setup you have to deal with, and the small mistakes that get in your way, before you can wrestle with whatever interesting programming problem you’ve set your sights on. Writing unit tests feels like more of that setup to me, and indeed would be. That’s why I’m resistant, because they would be “yet more stuff” to deal with before getting to the fun parts.
However, and sadly, producing good code isn’t just about the fun parts. To finish anything, never mind to finish anything good, you have to get through all the other stuff, the stuff that’s not the interesting core. For me, writing documentation is a way to go about motivating myself to deal with the non-core parts. As I write the documentation, I find that instead of being willing to document the flawed and redundant and hacky stuff that I left in there to just make it work while I spend more time on the next fun part, I end up rewriting the bad parts and getting into that kind of polishing.
This suggests that writing documentation from the start would help, but the problem there is that often I have to change my approach some of the way through, and so the documentation would have to change. Writing documentation before things are lockeddown just seems like a terrible waste.
Unit tests, however, are something between these things. They’re a kind of documentation, in that they strictly define at least some expected output, and whatever you write must match at least that much. They also force some clearer up-front thinking about how things are supposed to work and to fit together—up-front thinking that often, in my case, gets left aside in the rush to finish with the dastardly setup and get to the fun.
Apart from likely forcing me to produce better code, I suspect that in the long run unit tests save time, because the warnings and feedback they provide should help cut down on the time spent on “setup” in the midst of a project, when the lack of tests to tell you why something stopped working some number of changes ago means a lot more time spent troubleshooting instead of doing interesting coding.
So, tomorrow I’ll aim to either get somewhere with head-to-head or set up at least a basic test of some kind for the project.