I've tried that and found it didn't work out all that well. In order to write a sensible test, the feature more or less has to be completely designed.

That's the point. :)

You have a feature you want to write. Instead of asking yourself "How can I get my code to do this?", you ask yourself "How can I write a test that proves my code can't do this?" In the process of writing that test, you will discover the design of the code that will make the test succeed. This is the Zen beauty of test-first design. Then you add more tests until you can no longer think of ways to break what you've written.

This ensures that you don't do too much work. So long as you only test those things you need, and you don't write anything that isn't contributing to making a test pass, you're not over-designing, or succumbing to bloat.