on 20 November 2009
Growing Object Oriented Software, Guided by Tests, by Steve Freeman and Nat Pryce is a TDD book, but unlike any other on the market today. First of all, the book deals mostly with advanced unit testing topics, such as designing tests for readability and mocking, and addresses many common stumbling points that people experience with unit testing a few years after they started their journey, such as applying unit testing in multi-threaded and asynchronous environments. Second, it explains and demonstrates in practice the dynamics of designing software through TDD, which is still a dark art for many programmers. And third, it gives the reader insight into Freeman's and Pryce's brains, which is why this book is a must-read for anyone serious about unit testing, even to people that have been doing it in the last century.
Given the authors' backgrounds, it's not surprising that this book has a lot to say about using mock object libraries. Mock objects are arguably the most misunderstood and misused concept in software development today, so this book should be a valuable resource for most software development teams. In the part dealing with mock objects you will find strategies for using them successfully for software design, guidelines what to mock and what not to mock and lots of examples how all that looks in code.
The book isn't written in the usual imperative way ("you should use this because of...") but reads much more as an experience report ("we use this because of"). This might be unusual at first but I really like it, as it puts the things into a much more different perspective. Many of the topics addressed by this book are quite controversial and the authors have wisely chosen the voice to avoid any notion of preaching. I found myself disagreeing with parts, especially around bundling acceptance and end-to-end testing together. However, as the material doesn't preach but tell what the authors are thinking about, this did not bother me at all.
All in all, an excellent book. Grab a copy now.
on 4 December 2009
Some of the other reviewers are referring to this book as 'advanced'. I think it's advanced if you're relatively new to TDD. It would certainly help if you're a competent developer (which is probably why you're looking at TDD anyway), but it's 'advanced' if you want to change the way that you develop software.
It's a good read and I found quite a few "aha" paragraphs (my copy's now punctuated with permanently folded corners/post it notes).
It's nicely written without sounding arrogant. I think it's quite a hard topic to cover without getting bogged down in the minutiae of whys and wherefores of decisions, which it covers at exactly the right level
My only criticism is that I found it wee bit annoying the way it referred to the latter worked example when introducing an aspect of TDD, forcing me to skip back and forth a bit - but I think that's just a personal book reading preference.
I'm not sure how much an experienced TDD practioner would gain from it (except to see some of your own thoughts mirrored in black and white), but would very much recommend it to those new or getting started with TDD, wishing to `do it right'
Although the code samples are in Java it is applicable to other languages, such as C#, as the concepts are language independent
on 15 January 2010
This book is excellent, showing you not only how to do great TDD, but also how to do great design.
I would recommend it to all programmers out there who can read Java.
(The one caveat is that the book is all in Java, and so if you find reading Java hard you won't get as much out of the book.)
Steve and Nat walk you though a non-trivial example over many chapters which allows you to see how they think and how they write code.
Of course they use evolutionary design. So if you haven't got much experience with evolutionary design this book will show you how it works in practice.
TDD has improved and evolved over the years, making many of the earlier books on TDD seem outdated.
This books is full of personality and show how Steve and Nat approach TDD today.
I liked the state transition diagrams they used to visualise the system, and show which bits have been tested, and which bit is currently being worked on.
on 21 November 2009
As other reviewers have mentioned, this is an advanced book. It covers TDD methodology and programming concepts in great depth. The book explains in detail what should a good test achieve and shows you many techniques that could help improving your tests. Moreover, it emphasises the importance of code quality not only in production code, but also in tests.
This book doesn't read like a boring text book. Reading the book feels like going through Steve and Nat's secret notebook, containing their valuable experiences and lessons learnt.
Although the code examples in this book is Java, I find most concepts are very applicable to other languages if you do TDD. Beginners may find this book too high level, but I think it's a must read for TDD practitioners who want to further improve their art.
on 9 December 2009
This is the best book on TDD that I've read. It's more than just about testing though - it's about object oriented design. It's very well written - clear without being verbose. It's suitable for all levels of experience of TDD. Unlike other books on TDD I've read, there is plenty in this book even for people who have done plenty of TDD before.
on 27 July 2013
I've been a programmer for 18 years now, and there a few cornerstone books that changed my world view - this is one of them.
I consider myself an experienced programmer when it comes to Test Driven Development. I've picked up the practice back around 2003, when I first read Kent Beck's XP Explained. The habit was further reinforced by Martin Fowler's Refactoring book, and those 2 guys are my programming idols to this day. I hope I grow to have as much an open mind to experimentation as they have.
After watching Kent's screencasts on TDD by the Pragmatic Programmers, I felt pretty confident I was doing the "right thing"™ when it came to TDD. I later interviewed with ThoughtWorks, and had some harsh feedback on my TDD skills. This is one of the books they told me to pick up in order to toughen up, and boy were they right.
Steve and Natan dig deep into "modern" mockist TDD, building a real application with a UI and testing it both inside-out and outside-in with unit and acceptance tests. While mocks and behaviour driven development are not new things as they were when they wrote the book, the practices and hints they give throughout the book will be just as valid as they were a few years ago.
Along with Eric Evans' DDD book, this is a must read and must have for anyone that considers themselves a professional programmer. My TDD skills have levelled up much after following the book, and most importantly, I have a reference to look into when I found myself stuck in a corner with a "real world application" and testing.
on 31 May 2011
I'll cut straight to the chase: This is a great book! In fact I'd put it second, behind Test Driven Development by Kent Beck, on my must read list for developers. Testing is so important and while Unit Testing is becoming mainstream, many are failing to take the next next few steps to integration and system (end-to-end) testing. This book tells you why you should and shows, with practical examples, how to get started.
Growing Object Orientated Software Guided by Tests was the first place I read about the Walking Shelton. Originally described by Alistair Cockburn, this is a technique I've been using for the last few years and didn't realise there was a name for. The Auction sniper example that covered by the middle chapters introduces not only testing techniques, but lots of useful and practical lessons about good design. The later chapters discuss improving your tests, including readability. The final two chapters cover testing threaded code and asynchronous code. Some of the ideas presented here were new to me and would have have been very useful refactoring exercises for some projects I used to work on.
If you want to develop higher quality, robust software, read and apply the lessons in the book.
Warning: The code examples in the Kindle version of this book are difficult to read and there are a few misprints compared to the paper version.
on 20 November 2009
This isn't a book for beginners. It's a book for competent or expert programmers looking to become even better.
As you go through the book it feels like you're paired up with an articulate expert, guiding you through the process of developing a non-trivial application from scratch. I haven't come across many (any?) other books that describe the process and reasoning behind development decisions so clearly and in such detail.
If you're a strong developer (especially if you're familiar with Java) I highly recommend this book. You'll get a lot out of it.
on 8 April 2012
This book fundamentally changed my understanding of TDD.
It is the first clear, detailed description I have seen of how test-driven development (TTD) not just improves the quality of code, but can and should be used as a driver to change the actual design of the code. In other words, why you don't merely write less buggy code with TDD, but fundamentally different (and better) code.
The book describes how to kick off a new project with a "walking skeleton" - a minimal end-to-end feature that exercises the entire automated build-deploy-test infrastructure that you will need for the rest of the project.
It describes how end-to-end acceptance tests differ from unit tests and integration tests, and how the three types fit together.
Much of the book is an extended worked example, including asynchronous networking and UI code. This level of detail requires effort to read, but prevents the authors from hiding behind any form of hand-waving, and is well worth the effort - I am currently re-reading all the way through.
If you aspire to test-first programming then you need this book. If you don't aspire to test-first programming then you should read this book.
on 25 March 2010
This book has changed the way I code. As someone that has been coding for 20 years and using TDD for 3 or 4 years that is as clear a recommendation as I can think of. I thought I understood TDD and the reasons for it but this book exposes the true beauty of the approach. There is some excellent advice in here that any developer using TDD should know. If you are using TDD (and why not by now) then read this book.
My only complaint with the book was in Part III which is a worked example. This is a large part of the book that uses a development example to demonstrate their approach to software development. As such the code goes through a lot of refactorings and this is where the problem lies. Too often they discuss a refactoring that is required without showing the code that they are considering refactoring. As the code has already gone through so many changes it is very difficult to keep track of what it currently looks like.