This site uses cookies to deliver our services, improve performance, for analytics, and (if not signed in) for advertising. By using LibraryThing you acknowledge that you have read and understand our Terms of Service and Privacy Policy. Your use of the site and services is subject to these policies and terms.
Hide this

Results from Google Books

Click on a thumbnail to go to Google Books.

Growing Object-Oriented Software, Guided by…

Growing Object-Oriented Software, Guided by Tests (edition 2009)

by Steve Freeman, Nat Pryce

MembersReviewsPopularityAverage ratingMentions
190388,942 (4.05)1
Title:Growing Object-Oriented Software, Guided by Tests
Authors:Steve Freeman
Other authors:Nat Pryce
Info:Addison-Wesley Professional (2009), Edition: 1, Paperback, 384 pages
Collections:Your library

Work details

Growing Object-Oriented Software, Guided by Tests by Steve Freeman



Sign up for LibraryThing to find out whether you'll like this book.

No current Talk conversations about this book.

» See also 1 mention

Showing 3 of 3
A great read for anyone interested in automated testing and TDD.


* Makes a strong case for testing: better design, faster feedback, user experience first, regression, and most importantly, the confidence to make changes quickly.
* Includes a nice walk through of an iterative, test driven development process of a small app.
* Lots of great examples of how "listening" to tests leads to better design (ie, what the "driven" really means in TDD).
* I learned a lot from the discussion of how to make tests readable and maintainable.


* The book is 100% Java. How do these lessons apply to other OO languages?
* The authors spend too much time selling the jMock framework
* The app they develop iteratively is a Java swing app full of distracting details like the way Swing manages threads. It was a bit boring at times and the code was verbose, so it was easy to lose focus.

Fun quotes:

What if software wasn’t “made,” like we make a paper airplane—finish folding it and fly it away? What if, instead, we treated software more like a valuable, productive plant, to be nurtured, pruned, harvested, fertilized, and watered? Traditional farmers know how to keep plants productive for decades or even centuries. How would software development be different if we treated our programs the same way?

As John Gall wrote in [Gall03], “A complex system that works is invariably found to have evolved from a simple system that works.”

In our work, we apply feedback cycles at every level of development, organizing projects as a system of nested loops ranging from seconds to months, such as: pair programming, unit tests, acceptance tests, daily meetings, iterations, releases, and so on. Each loop exposes the team’s output to empirical feedback so that the team can discover and correct any errors or misconceptions.

One lesson that we’ve learned repeatedly is that nothing forces us to understand a process better than trying to automate it.

Our experience is that, when code is difficult to test, the most likely cause is that our design needs improving. The same structure that makes the code difficult to test now will make it difficult to change in the future.

When composing objects into a new type, we want the new type to exhibit simpler behavior than all of its component parts considered together. The composite object’s API must hide the existence of its component parts and the interactions between them, and expose a simpler abstraction to its peers.

In most systems we build, we end up writing a runtime exception called something like Defect (or perhaps StupidProgrammerMistakeException). We throw this when the code reaches a condition that could only be caused by a programming error, rather than a failure in the runtime environment.

By repeatedly fixing local problems in the code, we find we can explore the design safely, never straying more than a few minutes from working code. Usually this is enough to lead us towards a better design, and we can always backtrack and take another path if it doesn’t work out. One way to think of this is the rock climbing rule of “three-point contact.” Trained climbers only move one limb at a time (a hand or a foot), to minimize the risk of falling off. Each move is minimal and safe, but combining enough of them will get you to the top of the route. ( )
  brikis98 | Nov 11, 2015 |
Maravilloso libro sobre el pensamiento architectural usando TDD.Tiene un explicación muy detallada de cómo abstraer un sistema orientado a objetos y verdadero significado del paradigma OO
  agilenature | Jun 23, 2011 |
Good book but its completely Java oriented (more than i expected) so not too much to learn for .Net oriented people.
Still there are some very good chapters for every professional like chapters on unit testing threading and asynchronous calls etc.
Also first-hand chapter on history of mocking is very nice. ( )
  spavkov | Mar 31, 2010 |
Showing 3 of 3
no reviews | add a review
You must log in to edit Common Knowledge data.
For more help see the Common Knowledge help page.
Series (with order)
Canonical title
Original title
Alternative titles
Original publication date
Important places
Important events
Related movies
Awards and honors
First words
Last words
Disambiguation notice
Publisher's editors
Publisher series
Original language
Canonical DDC/MDS

References to this work on external resources.

Wikipedia in English


Book description
Haiku summary

Amazon.com Product Description (ISBN 0321503627, Paperback)

Foreword by Kent Beck


"The authors of this book have led a revolution in the craft of programming by controlling the environment in which software grows.” --Ward Cunningham


“At last, a book suffused with code that exposes the deep symbiosis between TDD and OOD. This one's a keeper.” --Robert C. Martin


“If you want to be an expert in the state of the art in TDD, you need to understand the ideas in this book.”--Michael Feathers


Test-Driven Development (TDD) is now an established technique for delivering better software faster. TDD is based on a simple idea: Write tests for your code before you write the code itself. However, this "simple" idea takes skill and judgment to do well. Now there's a practical guide to TDD that takes you beyond the basic concepts. Drawing on a decade of experience building real-world systems, two TDD pioneers show how to let tests guide your development and “grow” software that is coherent, reliable, and maintainable.


Steve Freeman and Nat Pryce describe the processes they use, the design principles they strive to achieve, and some of the tools that help them get the job done. Through an extended worked example, you’ll learn how TDD works at multiple levels, using tests to drive the features and the object-oriented structure of the code, and using Mock Objects to discover and then describe relationships between objects. Along the way, the book systematically addresses challenges that development teams encounter with TDD--from integrating TDD into your processes to testing your most difficult features. Coverage includes


•   Implementing TDD effectively: getting started, and maintaining your momentum

    throughout the project

•   Creating cleaner, more expressive, more sustainable code

•   Using tests to stay relentlessly focused on sustaining quality

•   Understanding how TDD, Mock Objects, and Object-Oriented Design come together

    in the context of a real software development project

•   Using Mock Objects to guide object-oriented designs

•   Succeeding where TDD is difficult: managing complex test data, and testing persistence

    and concurrency


(retrieved from Amazon Thu, 12 Mar 2015 18:11:02 -0400)

No library descriptions found.

Quick Links

Popular covers


Average: (4.05)
1.5 1
2 1
3 3
3.5 1
4 6
5 9

Is this you?

Become a LibraryThing Author.


About | Contact | Privacy/Terms | Help/FAQs | Blog | Store | APIs | TinyCat | Legacy Libraries | Early Reviewers | Common Knowledge | 129,572,999 books! | Top bar: Always visible