Remember back in college when you would come up with 2 pages of good material then bs it into 5 to meet the length requirement? This guy does it to make a 200 page book.
Test-Driven Development is not very complicated. You can fully understand it just reading the wikipedia article on it. This book doesn't explain much more than that. There are a ton of examples for just about any situation you can think of inside this book, but any decent programmer could just look at an example or two online and be just as well off.
This book would be most helpful to someone who has just started learning programming on their own (no degree or job experience), but this book is mostly just a waste of time.
Really not that good.
I was expecting quite a lot from this book, because it has been recommended so many people and organizations. However this was a disappointment. I feel TDD is important topic and way to go, but this book is not the one I would recommend to anyone. It's kind of reference book, but quite poor one.
Another silly development fad...
TDD "By Example" is a book that tries to persuade you to write tests before writing the code the tests test. In the first six chapters, the author takes you through an example of generating code through this method. Along the way, he makes several pertinent points:
1. His method has never been empirically studied to see if it helps or severely hurts the efficiency of the software development process (though the author is very interested to hear from anyone who finally DOES study his method, since he didn't have the time to do so himself, being too busy dreaming up new development processes to inflict on us).
2. His tedious, non-linear, haphazard, time-wasting (ed: my words) method is not meant to be followed precisely, but only meant to allow you to say you CAN do it that way. He makes this point numerous times. Fantastic dude, thanks. :/
I predict that this book will be purchased by software project managers both actual and wanna-be all throughout the software industry, and inflicted as a requirement on otherwise productive and smart engineers for several years to come. The final result will be projects woefully behind schedule, leading to inevitable 24-hour/7 day crunches, thereby twice punishing the engineers, and resulting in the whole silly process being dropped in the end.
Having said all this, I give the book two full stars: the english grammar is correct, and the punctuation well placed. The book is easy to understand, making it quite simple to dislike the content thereof.
Extremely important software development practices
Excellent book, well paced and informative. You should really go through the examples as you read those sections (part 2), even if they feel a little obvious, because if you are new to TDD you will pick up some insights. I particularly liked the Patterns section (Part 3), as it introduced some new patterns as well as talked about familiar patterns in the light of TDD.
If you are a software developer, you must put this powerful tool (TDD) in your toolbox.
intriguing ideas, irritatingly presented
The book's scope is well-defined and its methodology (including a running "task list" that is updated at the end of each chapter with strikeouts and new items) is innovative. But it falls sadly short in execution.
The text is overloaded with cutesy digressions that only serve to obscure the topic at hand and irritate the reader. No "Head First" title, this. To read this book is to wish over and over that its author had had the humility to submit it to another editor's series rather than launching it under his own.
Still, there is no other book quite like it on this subject, and I can certainly recommend it for extended bookstore browsing. You may find you are less sensitive than me to Beck's assaults on clarity, in which case by all means go forth and buy.
