This might be my own personal failing, but those tests will never get written. Once the feature works, the temptation to move onto the next thing is just too great.
Also, by writing the test first, you ensure that the code is actually easy to test. This gets easier as you get more experienced with testing, but still.
Also, writing the test first helps in identifying a sane API, I personally consider this to be the single greatest advantage of TDD.
I don't write as many tests as you do though, Steve. I generally stop once I have the nominal test cases in place, I don't test edge cases. They seem to tend to get hit by upstream unit tests anyway (I don't mock except where it is absolutely necessary). If I do hit a difficult-to-find bug, I use tests as one of my main debugging tools, writing tests for any code for which I have some doubts. By the end of a project, I generally have a fairly high code coverage for my tests, but I never feel like I'm just writing them for the methodology - they are either testing the nominal case, or testing to verify behaviour when tracking down a bug
I totally forgot about this, but I agree 100%. I'm a big fan of "Write this as though the underlying code exists, then fill it out" for API design.
I don't write as many tests as you'd think I do, actually, because I heavily favor integration tests over unit-style tests, and so we're probably much closer in that regard than you think. ;)
Also, by writing the test first, you ensure that the code is actually easy to test. This gets easier as you get more experienced with testing, but still.