Project X report

[prog]

X is chugging along nicely. The skeleton of the logic library is complete, and I'm now fleshing it out through writing a whole mess of unit tests, making sure all the muscles twitch just so. It's hard to imagine a time when I didn't make a habit of test-driven development, even though I started only a couple of years ago. Seeing the panel of lights glow green after adding code is a happy thing, and seeing some turn red is happier, in a way, because I know that here are errors I wouldn't have caught until much later without the tests handy.

I'm champing at the bit to start working on the UI, partly because it terrifies me. But I'm not letting myself do so until every class (or at least every class of class) has at least a couple of tests attached, and there are a lot of classes. There's probably another two or three full work-sessions of test-writing in front of me, and when I do start building the UI I know I will be on my knees thanking my past self for having the patience to do them first.

Moreover, it's past time to seriously engage the game's rights-holder about what they expect to see on their end of the licensing deal. I made a gesture towards this over email last month, and they acknowledged receipt, but we need to have an actual conversation. I've been putting it off because it's less fun than working on code by myself, but I have long since proven to myself that I can accomplish the technical end of this task. Time to refocus long enough to TCB.

Comments

[radtea.livejournal.com]

I've tried at times to do test-driven development, but either I'm doing it wrong, or the kind of stuff I do is not susceptible to it. Part of the problem is a lot of the algorithmic code I write has no better answer than the one the code provides: there are no closed-form solutions that could provide test cases, and even stable trivial cases aren't testable in a meaningful way because the results are subject to interpretation. So when I've tried to do test-driven stuff I've wasted huge amounts of time debugging test failures only to discover that the test has failed for trivial reasons.

For example, having done a lot of hardcore numerical programming on Intel architectures, adopting a test-driven approach taught me a few years ago that a lot of the math is done in 80-bit registers internally, which creates miniscule changes to 64-bit arithmetic depending on initialization conditions. This kind of thing gives any sane set of numerical tests fits, because it can make the difference between a "near miss" and a scatter in multi-particle Monte Carlo simulations, and means that at best you need different tests for debug and release code.

My approach has therefore tended strongly toward imposing runtime post-conditions on processes--in physics code, things like energy conservation, for example--which is certainly test-oriented, and keeps my bug-count extremely low, but is quite different from the usual external test suite that real test-driven developers use.

If you have any pointers to good resources for test-driven development I'd be interested in looking at them.

[prog.livejournal.com]

It makes sense to me that macro-scale testing I write about here starts to break down the closer you get to the raw computing metal.

That said, the tests I end up keeping tend to be pretty high-end, taking the software as a whole and bashing it through a gantlet of artificial test cases. This might not be what purists would call real TDD, where every single method needs a test hanging off it.

The book that taught me about test-driven development is "Perl Best Practices", which, yes, isn't necessarily a good generalized source (even though it did change the way I write code in all languages). Anything else I could point you at would be borne from the obvious Google searches.

[radtea.livejournal.com]

Thanks! That's exactly the kind of thing I was looking for: I've done the Google thing pretty heavily on this topic and not come up with anything that really does the job for me. I'll have a look at the book--a lot of good practise is language-independent.

Method-level testing is the kind of thing I use internal constraints for. Higher level testing, ideally with tests that can be tied to design goals, is the thing I'd really like to automate.

[radiotelescope.livejournal.com]

I've never exactly done test-*driven* development. I've done a lot of development that included unit tests in parallel.

I generally find that unit tests fit really well with some levels of the project, and make no sense for other parts. I never wrote any tests at all for Volity Fluxx, for example. But there are lots for various pieces of the Python parlor framework that I wrote Fluxx on top of.

(I could explain why this happened, but it might wind up as an argument for Jmac to stop writing Fluxx unit tests!)