So there are a lot of advantages to using TDD, they are well documented and there are plenty of people who extol its virtues.
One of them however has resonated with me of late. And that is how it effectively builds a living document of the implemented functionality of your system.
I am working on a personal project, and the time I can spend on it is quite sporadic. Between work and a young family, time to code for fun is quite broken - 10 minutes here, an hour there, a weeks break, another 10 minutes and so forth. It doesn't make for much of a flow.
But what I have found is, by sticking to TDD and by using test names that are informative that I have built a living document of what I've implemented. So when I come back to the code even for a moment I know where I am. Run the tests, and green, there is all my functionality.
Better yet, the breaks force me to revisit my naming, and I actively refactor the code (including the tests) to try and make it more readable.
I've also found that by invoking the "if its not green at then end of the session then ditch it" rule quite effective too. Now you might say that if you only have five minutes to work on it then chances are you're not going to get to green. And a lot of the time its true - but before I stop, I roll back to green.
Now at first that seems counter productive, as the tests will show where its broken and you know where to come back to - but in practice I have found that it actually tends to mislead me, particularly if I have been away from it for a while. So better to return to a clean slate. Then what I find is that my subconscious tends to chew on the problem for a while, and when I come back to it I find my flow much quicker.
So its just another reason to use TDD and descriptive test names.