Controversy time. I just came across the essay Test-Driven Development is Stupid by Ian Mallett, and it made me feel a whole lot better about not having written a test suite for MeTal just yet.
Mallett's argument is that TDD is built around the idea that "you're trying to make a design before you learn anything about it." In other words, you should build your software to work in the real world, with all its messiness and paradox, and not to satisfy a bunch of tests that might well not cover those cases. More to the point, you should find out what your software is going to be first, before trying to build tests for it, because otherwise you're building tests for something that is potentially a giant moving target.
One possible counter-argument to that is, "Well, that's more a flaw of the test cases not being comprehensive enough." True, but I see where Mallett is coming from on another level. Software is by definition a fluid construct, so it's best to figure out how it'll actually work in the real world -- the iterative process of creating something, modifying it, tossing it, starting over -- before trying to create test cases for it.
MeTal right now is in such flux that any attempt to create test cases for it would be doomed. Instead of one thing to manage, I'd have three -- the software, the test cases, and the test routines themselves. It doesn't make sense to try and dope out any of that when I'm not even sure where a given module is going to live, what it's going to be called, or even if it will continue to exist in another six months.
It makes more sense, now that I think about it, to get the product to something like stability before attempting to write test cases against it.
I still think, in the long run, a test suite makes sense. But trying to write a test suite against something as protean as this project right now is like trying to -- what's that old phrase again? -- nail jelly to a tree.