Like most programmers, I've been writing bits of test code all my life; but I've never embraced Test-driven development (TDD). There are many reasons, but probably the principal ones were an expectation that TDD would slow me down and a belief that my existing methods worked fine—at least in the context in which I have worked for the past few decades.
Circumstances change and one of the changes facing me is that I appear to have spare cycles that could be applied to some free software development. Finding myself ready to begin creation of a new utility—for myself, but with wider usefulness likely—I thought I'd devote a day to experimenting with TDD. It has been an interesting experience.
Yes, it did slow me down, mainly because I was getting used to a completely new way of writing code and, to a lesser extent, because I was writing more code than I would have in the past. It will take me some time to get up to speed with TDD, but I can envisage a time when I could expect to travel at about the same speed as I'm used to. I take that as a positive lesson from today's experiment.
The more interesting discovery, for me, was something that I had not thought about at all, although it should have been obvious from the reading I had done. The process of small discrete steps (write a little test, watch it fail, write a little code to make it pass, refactor, repeat) keeps things in a state where the usual interruptions are much less of an issue. My usual way of working involves holding a substantial mass of code in mind at any time and interruptions are a real killer. I can usually arrange for blocks of uninterrupted time, but that's not always possible.
Today, while I was at my least amenable to interruptions because I was learning something new, it just so happened that my spouse needed to interrupt me several times. Each time I was able to turn away from what I was doing and resume fifteen or thirty or more minutes later without any stress—the small step that was interrupted turned out to be easy to resume without any difficulty. That alone seems like a reason to keep going with TDD for a few months to see if it can become part of my approach.
And, to return to the original issue, provision of a full unit test suite should make it much easier for other people to take the code and adapt it for their own purposes.