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
- check all tests still pass
- rinse, repeat.
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.