Test Driven Development

Just finished reading this. Interesting, but not entirely convinced.
Essentially, Beck lays down the following development procedure:

• write an (automated) test
• run the test to show it fails
  
• do the quickest thing possible to get that test working, even if it's really dirty or evil
• fun the test to show it passes
  
• refactor
• check all tests still pass
• rinse, repeat.

The main thing to notice is that the tests you write drive the functionality, rather than the functionality dictating what tests you write. The outcome of this is that the software is designed as you go, and essentially has the minimum possible clean design for the software at each point in the software's life.
It sounds good, but when I ran through his examples, I couldn't help feeling there is magic involved. I think my main concern about the methodology is that the design must necessarily wander around a great deal, and I can't help but think that this would waste a lot of development time in refactoring from design to design. Beck suggests that to some degree, this happens anyway, and IDE refactoring tools are getting really good these days to help with that.
I completely agree that having unit tests that give you a really high code coverage makes it much safer to refactor code, and continuous refactoring of code is really important as new features and modelling enter the fray, and the design necessarily morphs over time. If anything, having read this book will make me write even more unit tests.