Customer Reviews

Growing Object-Oriented Software, Guided by Tests

5 star:		(13)
4 star:		(5)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

This book has been in my Amazon pre-ordered list for quite a while and I was looking forward to this. I found the title alone already excellent. Steven and Nat (authors of jMock) are well known expert TDD practitioners, so I was looking forward to what they had to say. The book was better than I had expected.

The book consists of 5 parts. The first part of a very quick introduction to TDD and jMock. The second part discusses the tdd cycle in more detail. The third part (150 pages) is a very large example of growing a piece of software. The fourth part discusses topics on how to sustain TDD and the last part covers some advanced topics.

In this review, I'll skip part 1 as it was short and nothing special. Part two covers the TDD cycle and the link to evolutionary design. Steve and Nat have a design style that focuses almost purely on the interactions between classes which are most frequently tested using expectations on mock objects (which, as authors of jMock, they have lots of experience with). Most notable from part 2, for me, were the classifications of objects that they used, the strong focus on interaction and mocking (more than I usually have when test-driving) and their lack of focus on classes but focus on roles and responsibilities. Nat and Steve clarify their thinking exceptionally well which makes it all easy to understand.

Part 3 takes the largest part of the book, which is where they test-drive an AuctionSniper application. It is a small application, but large for a book example. The authors show how they gradually build up the application by adding one test at the time and how they gained insights during this process which made them adjust their design. I had mixed feelings about this part as a book didn't seem like the best medium for doing this, but still I appreciate the insights they had and also their attempt to make it as close to "real world" as possible.

Writing tests is one thing, maintaining them in another. Part 4 discusses how to make the tests maintainable and the tdd cycle sustainable. Personally, I found this part very insightful and the authors discipline exemplar. The authors start of with different test smells and what to do about it. They then discuss readability of the tests and of the error messages and spend some time of test object creation. Most notable from that part (for me) was their focus on using builders for creating test data, rather than object mothers.

The final part covers three (or actually two!) advanced topics. First is testing persistence where most interesting was how the authors seemed to prefer to "go all the way" whereas the common advise (for test speed) is to rollback and mock more. (this was actually a common theme in their book). The last two chapters deal with multi-threading and async code. I was unclear why these were separated in two chapters and they they were in this particular order. The content was excellent though, except that I missed some typical design guidelines related to multi-threading design. It almost felt they were in a hurry to write the last two chapters...

Anyways, in conclusion, this will definitively be one of my favorite (if not the favorite) TDD books and general design books. Steven and Nat did a wonderful job on this one. Though the book is not perfect, I enjoyed it thoroughly. A definite recommendation for anyone interested in modern design and TDD.

There are many books about Test-Driven Development on the market, but this book is unique. It presents a style of TDD which originated in the London software development community. It's a style which pushes several key ideas to the extreme: "tell, don't ask" object design, fully end-to-end incremental development, and the deep synergy between testability and good design. Steve and Nat have done a stellar job refining and presenting these ideas. The text is lucid and precise. When you read this book you'll be exposed to far more than just another style of TDD, you'll be exposed to a depth of insight about emergent object oriented design which is both rare and extremely valuable.

In a way this book presents the essence of a decade of test-driven development practice. The authors bring together the various tools of uptodate TDD like mock objects, bdd-style naming and acceptance tests. Open the book on any chapter and you will most likely find useful and deep advice, even if you consider yourself already a TDD expert.

There's one catch, though, that made me lower the rating to 4 stars: The authors go for an extended example which covers the full TDD cycle; from a walking skeleton, to the first acceptance test, into many obvious and some non-obvious refactorings. As noble as this endeavour is, it didn't work for me as a reader. Coming back to the text - and the code - after a day or two I often got lost trying to grasp the subtle nuances; I just couldn't remember all the necessary details of previous chapters.

Nonetheless, it's an excellent book and I enjoyed it. Get a copy, read it and become a better TDD practitioner.

The book "Growing Object-Oriented Software, Guided by Tests" By Steve Freeman and Nat Pryce is packed with so many extremely useful information about writing object-oriented software with tests that I once had to stop reading it as I was afraid I would have gotten a bit carried away. Each and every page has its purpose. Each presented me profound wisdom of Test-Driven Development (TDD) and during the time of its reading I couldn't stop wondering when and how to apply it in my development activities (I still haven't, but am working on it). It's without a doubt a very informatory book about practices and theories behind TDD and jMock. There is no excuse for skipping the book while developing your software as well as software development career itself.

The book consists of 5 parts, 27 chapters, 3 appendixes and almost 350 pages. After 8 informatory chapters of the Part I: "Introduction" and Part II: "The Process of Test-Driven Development", the Part III: "Working Example" appears in which you will learn what it is to write an exceptional book about TDD by its practitioners. It was then when I let myself take some time off reading the book. Following the Part 3's chapters strained every nerve of mine to fully understand the TDD concepts. The authors did a good job of explaining TDD theory focusing on its practical aspects like early feedback, code quality, readability and maintenance.

It's definitely not a book that you read and forget. It is one that you read and never forget. It is one that requires a lot of attention on your part and leaves no stones unturned in pursuing well-thought-out object-oriented software development. The last Part V: "Advanced Topics" was quite hard to follow, perhaps because it touched the concurrency and asynchrony concepts I'm not very good at and interested in. I then enjoyed the Afterword: "A Brief History of Mock Objects" where I learnt the history of jMock in quite a humorous way. Opening each chapter with a motto was highly motivational and made the reading even more enjoyable experience.

I think it'd be better off if the book became a mandatory reading for all who wish to master the art of object-oriented software development.

This book seems to have been well received by the TDD community, however I was somewhat disappointed. I might write a fuller review later, but for now I will just make some brief points.

Some time ago I read the original book on TDD by Kent Beck. I wasn't that impressed to be honest. I disagree with the approach of test driven development. That is you write a test first, then do the minimum to make your application pass the test, then you add more tests, then you add more to the application etc. Normally I don't follow this approach as it seemed somewhat nonsensical. Instead I design my classes, then I tend to write tests to cover areas I regard as problematic. That isn't to say I follow a waterfall approach, as my program evolves, I often need to redesign certain aspects.

Back to the book. The first part gives a brief overview of TDD. Those without experience in this might feel a bit lost. The second part of the book gives a few more details about the process of TDD and the author's approach to OOD. The third part discusses an extended example which is an Auction sniper program. Basically the authors approach to TDD is to use appropriate tools to automate the build/deploy/test process and enable end to end testing of the application. These tools include "WindowLicker", "JMock", "JUnit", "Hamcrest"

I didn't really care for the extended example as I found it kind of tedious. Also the problem with extended examples like this is when you put the book down for a few days and come back to it, you have trouble picking up where you left off. In addition I sometimes found it hard to follow how the tools work.

Really the book's message can be summed up as "use TDD, test your application end-to-end", illustrated with a long Java example. To be honest my reaction to the long example was, "holy cow that is a lot of tests for such a basic application". If you don't use Java and you don't use the tools mentioned I can't see it as being that useful. If you do plan on using the tools mentioned, you might be better off reading dedicated tutorials rather than this book. Also although the books discussion on OOD was reasonable, other books are better, so I wouldn't read the book for that either.

In summary then although this is an OK book, I just didn't find it that interesting or useful.
Most people who liked the book appear to be experienced with the tools and TDD, and hence found reading the book quite easy and also compatible with their own views. People who aren't experienced with Java and/or TDD might be better to look elsewhere.

Let me say as well (not really trolling here) that TDD has become kind of a cult. Long before TDD came about people were writing good and bad software. After the appearance of TDD, people are still writing good or bad software. Also every few years something new seems to come along and if you don't follow it your projects are somehow destined for failure. Moreover there appear to be lots of people who jump on the bandwagon and try and make money through training and consulting in SCRUM, Xtreme Programming, Agile, TDD. However they don't appear to do much actual programming. It is hard to take these people seriously when they jump on each new trend. Really why should I listen when a couple of years ago you were saying method A was the way to develop software, now you are saying it is Method B. (Not saying that it applies to the authors of the present book who do in fact appear to be well respected professional developers)

Now there is one truism of software development and that is that people can often only write a certain number of lines of code a day. If you spend a lot of time writing tests of every aspect of the system, well that is going to use up quite a few of those lines of code. Personally I don't disagree with the concept of building tests for your system, but I'm still not sold on TDD as outlined in this and other books, also the tools used need to get more streamlined.

In conclusion then although I didn't really care for the book I can't say it is a bad book. Probably people who are already experienced in TDD, OOD and who use Java may find some useful insights in the book. Those who are new to any of these topics should look elsewhere.

The first part of this book seemed scattered, jumping all over the place and making a lot of reference to things which weren't defined until later in the book. However, once you get used to the style, this book jumps off a cliff and hits a lot of great topics, and hits them in depth.

Tooling, design, culture, methodologies - it's all covered, and it's covered fairly well. I particularly enjoyed the authors carrying the same detailed, practical example through the book. Too many software books use trivial examples specific to one topic. Freeman and Price evolve an "Auction Sniper" as they go through the book; the consistency is a great asset.

I also enjoyed the authors speaking emphatically about using acceptance tests as the starting point for features, not just unit tests. There's an important differentiation between acceptance and unit tests, and the authors specifically call out acceptance tests "using only terminology from the application's domain" - speaking to the feature's business driver, not the underlying technology.

Also as critical to me is the authors' emphasis on keeping the test side of the codebase clean. Your tests ARE production code. Treat them with the same approach about solid design and refactoring as you treat the code you're deploying to your customers.

This isn't a simple 100-level book. The authors dive deep in to design, practices, and lifecycle. They do it well enough that they'll hook newcomers to testing as well as teach accomplished folks new things too.

Great read.

Growing Object-Oriented Software, Guided by Tests is an excellent book by Steve Freeman and Nat Pryce. In it, as the title suggests, they describe an agile approach for growing software incrementally over time, using tests as a tool to provoke progress and to maintain focus on quality. The authors are the creators of the jMock mocking framework, and as such they approach the design of OO software with a heavy bias towards interface-based design.

The book is concise and very well written, it feels like it has been edited to within an inch of its life. It is full of tips and patterns for common testing challenges that can be applied to any project. The book is split into five main parts:
1. Introduction, explaining the motivation behind test-driven development and a basic high-level introduction to TDD. They explain the reasoning behind the Object-Oriented design principles that they follow in their process.
2. The Process of Test-Driven Development, describing the test-driven process they follow in depth. The key differentiator of their method is that they follow an "outside-in" development approach where they begin first by writing an integration test to define the feature to be implemented, then use a unit testing approach to tease out the implementation. For them, design for testability should be the highest design goal for software.
3. A Worked Example, where they describe the development of a complete system following their development approach. They start from the very beginning, getting a "walking skeleton" of the application up and running right through to adding functionality feature-by-feature. There are lots of code examples and you really should pay attention to get the most of this section. As the system is developed they describe the decisions and trade-offs they make.
4. Sustainable Test-Driven Development, techniques to make TDD projects work in the long term. Topics like test flexibility, test diagnostics and test readability are covered.
5. Advanced Topics, focuses on the tough topics in automated testing: persistence, multi-threaded, and asynchronous code.

This is a book which investigates what Michael Feathers calls the "deep synergy between testability and good design" in depth. It will teach you how to create cleaner, more expressive, more sustainable code. It might even change they way you think about software development. This book is definitely is my software book of the year.

I've been a TDD programmer for a few years now. I really enjoy the process. But, I was only doing it at the class level. This book as broadened my scope to apply TDD to every layer of the project. Now I do 0 Iterations and work end to end. Those two practices save me a great amount of time and pain just by themselves.

As far as I am concerned this is a must read for modern programmers. It is required reading for anyone I am mentoring.

This book deserves its place among the most important writings in the TDD and OOD field in the recent years. Its greatest advantage is the presentation of the continuous evolution of high-quality software guided by tests (as the title says it). While reading the third chapter, the audience may clearly see, how Steve Freeman and Nat Pryce really worked on their example project - sometimes making necessary tradeoffs, sometimes taking a step back and so on. From their experience with the example project comes a clear message to the reader about the deep synergy between pragmatic and to-the-point object oriented design and test driven development: if you make good OO analysis and design, your code is more testable - if you drive your code with tests, it will probably also positively influence your design. The authors not only describe this synergy, they also give some very valuable advice about how not to lose it in the long run of your project in the fourth chapter. Last but not least, the authors give a short theoretical introduction about TDD and some hints related to testing corner cases like persistence or concurrency. All in all, I highly recommend this book to anyone interested in Test Driven Development and Object Oriented Design.

The person who handed me this book said it was "better than Lasse's book" (Test Driven.) I disagree. One can't compare the two books - Test Driven is meant for beginners and this book is meant for an advanced audience. If you have never written unit tests before, this book is very hard to follow. So put it down, get an intro book and come back.

I really liked the emphasis on making the software responsive to change along with separating acceptance and unit tests. The book uses Junit 4.6 and therefore covers Hamcrest matchers for both JUnit and JMock. I like the authors cover best practices, good design and clearly indicate what is a personal preference. I really liked part 4's emphasis on things that are hard to test at a higher level than "extract method."

The only thing that prevents me from giving full marks, is the case study. While I did read this part in one sitting, it was still hard to follow. There was a lot of information to keep in mind while trying to focus on the lessons of the example. I also think it was admirable for the authors to use a Swing example since Swing is harder to test. However, Swing is also less common for Java developers to use actively adding another block to understanding the software growing/testing aspects. And it is even harder for non-Java developers who are in the target audience for the book.

Except for the case study, I thought the book was amazing. And I'm sure the case study is a matter of taste.


---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.