I am working on a fairly complicated set of parsing modules, and as I have written each one of them I have written a set of test-scripts.   I know that the modules passed all of those tests when written, but it is of course devilishly easy to “break something else” in this curious china-shop that we call our daily workplace, especially when you are parsing things and writing a lot of regular expressions.   It is therefore very useful to have a known set of things that “this code has been known to do without error,” and the means to test automatically that it still does.   (e.g. prove -r t/*)   You’d be surprised just how often it doesn’t work anymore ... and if you were not consciously looking, you wouldn’t know.   Yet.   Heh.

This has allowed me to avoid a lot of red herrings.   As you move forward through the writing process, and you (inevitably) discover another bug, it is natural to assume that it must be in the new stuff; that what was working before is still working.   But, more often than not, that is not the way it works out ... and the time-savings can be huge in the long run.

When you think you’ve got it finished, that’s when you start writing more tests ... what I call the “kick the tires and look under the hood” tests.   But that is not the time when you should begin writing tests.