Glad you're still using Tiny Tasks. Although we used them on our project to break down functional tasks, we did use them, albeit less occasionally, for identifying any dependencies.

Normally I would treat them as higher priority as I see integration points a higher risk, especially if it breaks existing behaviour.

On a different note, when I have refactored build scripts in the past, I would normally write manual test scripts (scenarios written down in a text pad). I think the payback for automating them is less, though I can still manually step through them and ensure I haven't broken any existing functionality.

I've only briefly looked at Ruby/Rake…would it be just as easy as testing Ruby code to write tests around your build? I imagine it probably would be but I've never tried it.

What sort of things would you imagine would be tested out of interest? The creation/deletion of directories, that the tests were actually run? Just trying to think how you would get the most benefit out of using this approach as I'm sure it could be useful.

Perhaps you should have a suite of tests. This is something I decided to try the next time I end up as a build monkey. I find that a lot of build tasks have a programmatically assertable behaviour. I just don't think that people have opened up to the idea of TDD for the build system.

Part of that reason could be Ant. Ant tries to deceive you into thinking that setting up a build can be a declarative process. It's really scripting though, and better done using a language like Ruby/Rake.