I will usually write one or a few tests that exercise ideal 'happy paths' before starting proper implementation, assuming it can be done fairly quickly. I don'

I will usually write one or a few tests that exercise ideal 'happy paths' before starting proper implementation, assuming it can be done fairly quickly. I don't hold on to these very tightly; they will often change as things go forward. Once I have those basic tests passing, I will often write a couple more tests for less common but still important execution paths. It's ok if these take a little longer, but only a little. Beyond the obvious 'test driven' benefits, I find that, especially for the first round, writing those tests helps me solidify what I'm trying to accomplish. This is often useful even in cases where I go in feeling quite confident about the approach, but there are some blind spots that are revealed even with the first level, most simple tests. I find the basic complaints that others have posted here about pre-writing tests largely valid. "Over-writing" tests too early on is, for me, often a waste of time. It works best when the very early tests can be written quickly and simple. And if they can't be, then I'll frequently take a step back and see if I'm coming at the problem from a poor direction.