This was the first book I picked up when I wanted to start writing code using TDD, and to this day it is generally the first book I recommend to anyone else looking to start.
The book is a very basic introduction to the world of automated tests and explains, in detail, all the topics that other literature assumes you already know. It mostly skips over some of the loftier and more advanced goals of automated testing (the design feedback, etc.) to concentrates on teaching the skills required to write really good unit tests.
It starts off with introducing the idea of unit testing and giving a list of properties that an ideal unit test should have, it goes on to introduce various unit testing frameworks and spends an entire chapter talking about mocking using hand-written mocks before introducing the idea of mocking frameworks, which gives the reader a good grounding in the theory of mocks before getting too tied in to specifics of a certain framework.
Then the book goes on to talk about the role of unit tests in a large code-base, and different ways of grouping, structuring, and running them. Following this is a large chapter devoted to writing tests that are readable and maintainable, pointing out common problems and possible solutions.
Finally the book talks about how to introduce unit testing to your organisation, including an excellent Q&A section which hopes to give good answers to the common questions that people who attempt to introduce unit testing are asked. This leads nicely on to the closing section of the book, which talks about how to apply unit testing to legacy code.
The title of the book does not lie, and it is packed full of example code which really helped me to get my head around these concepts when I was first learning, and the level of detail it applies to the basics of writing good tests means that a developer following the techniques described in this book will get a lot of the benefits of unit testing, even without having experience applying the design feedback such tests will provide.
I learned many good habits from this book that I still use today (case in point, I still use the MethodName_SituationBeingTested_ExpectedResult naming convention in all my unit tests, and find that when I struggle to name a test like this, it’s a good sign that I’m testing too much at once)
In summary this is a very good first book, but it is of limited use to anyone already familiar with the concepts of unit testing and mocking.