Starting with a test means that we have to describe what we want to achieve before we consider how.
2010, for me, was a year with quite a good reading list. It was when I first got to read some really good books such as Clean Code, Agile Software Development, TDD by Example and Apprenticeship Patterns. These are all stellar books I highly recommend.
Yes, indeed it was an awesome year and yet I can tell you that the best book I read this year is Growing Object-Oriented Software, Guided by Tests (GOOS, for short).
(GOOS, for short).I actually never heard of the authors before 2010. As opposed to books by authors such as Kent Beck and Robert Martin which one regularly hears about, I was quite astonished that I kept hearing about this book in different places.
I heard talks mention it, I saw lots of tweets about it and quite a few people that I highly value were praising it. This picked my interest and boy, am I glad I decided to add it to my pile.
I’ve read a lot about better development, better testing and better everything. And yet, I’ve never come across a book as thourough and as comprehensive as GOOS. If you read my other reviews you will see that what usually buys me over are good code walk-throughs. Now let me tell you, you haven’t seen a good walk-through until you’ve seen GOOS.
Code isn’t sacred just because it exists, and the second time won’t take as long.
On the one hand, the book is loaded with practical tips for making your tests better, faster, more readable and maintainable. It covers the nuances of testing ORM systems, GUIs, multi-threading problems and more.
On the other hand, every page turn is greeted with more nuggets of OOP lore. Actually, seeing all this wisdom clustered so tightly by people that have been struggling with these problems for over a decade now seems illegal to me. Are we really allowed to learn so many secrets of the profession this fast? Surely some sort of blood sacrifice has to be made?
Once we start a major rework we can’t stop until finished. There’s a reason surgeons prefer keyhole surgery to opening up a patient.
I’ve read GOOS over the course of a few months, consuming chapters little by little and letting the knowledge sink in. I was amazed at how much this affected my way of thinking about OOP and TDD, pretty much right off the covers. I already blogged about how my new OOP-Spidey-Sense helped us improve our architecture.
I’ll finish with saying this book is a game-changer for me, even though I’ve been doing TDD for a few years now. To the authors, Nat and Steve, I take my hat off. They have earned a place of honor in my Deserve-A-Beer list.
And to sum up all these great quotes from GOOS, here’s another gem:
The last thing we should have to do is crack open the debugger and step through the tested code to find the point of disagreement.