Reading this book was a mixed experience. While it addresses an important and often neglected topic, several aspects left me unimpressed and somewhat concerned.
The author presents some dubious techniques, such as using a glorified service locator singleton as an alternative to constructor injection (p.64, 2nd ed.), which would outright break parallel testing, without mentioning it. In fact, the book ignores the need for parallel testing altogether, presenting patterns which are not thread-safe as best practice techniques.
Some of the presented methods of creating testing seams in the code (such as using a service locator singleton, or exposing overridable methods solely for the purpose of testing - dubbed "Extract and Override") are unlikely to produce maintainable code, but the book makes no distinction between best practices and academic debate. Perhaps some of them were meant only for legacy projects, but that was not stated in the book. What's worse, some of those methods are described as the author's favorites.
For code reuse, the author suggests using test inheritance, completely ignoring composition or annotations, which in my opinion are usually much better alternatives.
Furthermore, the author claims that designing for code testability isn't important in dynamic languages, because code written in them is somehow inherently testable. To me, that's missing the forest for the trees - just because you can technically test something, doesn't mean you can test it well, in a maintainable and readable way. I was not successfully convinced by that claim.
Additionally, the book seems overly reliant on C# as the programming language. It's not just examples that are in C# - entire chapters talk about .NET tools for tests.
I was hoping to find answers to some tough questions of unit testing, but finished reading having not learned much more than I already knew.
It's not all bad, thankfully, and there are some solid basics of unit testing presented, as well as some great book recommendations (such as the works of Eric Evans, Robert C. Martin). Some good behaviors are also promoted, such as achieving 100% code coverage, though I was disappointed to see mutation testing being omitted entirely in that conversation. There is some genuinely good advice here (like using the Arrange-Act-Assert format, or only testing one thing at a time), but it's marred by the aforementioned issues.
In the end, I think it's an OK introduction for a beginner or mid-level C# developer - with the caveat that not all of the advice should be believed. Anyone more advanced is likely to find little value, unless they're really behind on their knowledge of mocks and stubs.
