Overall, the book is a well done explanation of test driven development. It lets someone who has never done this see the value of incorporating many tests of classes or methods into the code base, while the latter is still being developed. The author contrasts this with the traditional waterfall method, where programmers write code and get this to the testers to find bugs. This is considered too coarse grained and slow. In TDD, the decision loop is far quicker. So having a large array of unit tests is good. Along these lines, the book also advises on other aspects. Like when not to refactor, or when to stop refactoring. For example, if the code is broken in a certain area, you might not want to start or keep refactoring. Instead, fix the code first and verify using tests. Then refactor. In other words, refactor when all tests give green so that you start from a known good basis. But the book's advice might be too extreme. In one section, it suggests "write code only to satisfy tests". You are cautioned not to take this too literally. When making a program from scratch, or an entirely new code section, being constrained by that can slow you down. It is best suited for when there is an existing code base and you are making relatively small extensions. In practice, few experienced programmers will be able or indeed should adhere to "write code only to satisfy tests". The book overstates its case. Having said this, you should aspire to having as many unit tests as practical. And to automate the running of these. It can be a great comfort to simply run all the tests every day or so, to reassure that no known bugs have surfaced.