Growing Object-Oriented Software, Guided by Tests

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.

I've been involved with agile development with unit testing for 3 years now.I've read many books on the topics of ooad, oop, design patterns, etc.This book however, is quite niche.One of the the things that has eluded me thus far is the ability to use mock objects to assist in creating useful dsl's for my apps.I think this book may do just that.At any rate, this book is motivating me to join the Agile Alliance, so that I might meet these heroes of mine.For anyone that sees software as living designs and not just products, this book is a keeper, right up there with Fred P. Brooks's book: Mythical Man Month.As an aside, I recommend:Mythical Man Month (Brooks)Test Driven (Lasse)Test Driven Development (Beck)Head First Design PatternsJoel On SoftwareArt of Unix ProgrammingSoftware Engineering Economics (Boehm)etc (and any thing from anyone on the Agile Manifesto)

On the whole, this is an exciting book, one that shows that the book industry is not dead yet (although screening developers for an open position would make you think it were), but it's not what it thinks it is. It's almost comical, in a way, to see this book's conception of itself unfold. In the beginning of the book, it seems the authors believe they can show us ways to make TDD better. By the end, the Little Corporal is crowning himself emperor. The TDD/BDD historicity (and its nationalistic twinge) are ludicrous and add nothing to the book. Example of the Trump school of PR: DIY. On the substantive level, this book is confused about what it is because it takes its example (one of the best things about the book) as a representative of the world, which it most certainly is not.The example, which is detailed, thoroughgoing, and significant, is an auction application, and the focus in 'building' it is restricted completely to laying down the various protocols that dictate how parties interact through bidding, winning, losing, etc. This is not only not a serious picture of a project (as in one), it's laughable to be considered even complete for what it was. I am so bloody sick of examples that are of the form 'let's look at writing the 10 thousandth version of ______.' I am in software development (and love it) because it is invention. There is zero invention here. [Somebody, please address the part of the programming audience who are not ankle-chained to a rock pile, just once!]But there are other reasons why this 'work' is not representative. It's focused solely on the protocols in the program. If there were any honest, self-reflexive rhetoric in this book, the authors would have at least nodded toward the other things one would have to do to make an auction work. Their total absence beckons simultaneously to wizardry (Oz/Maxwell's Demon) and infantilism. What is JMock going to do to make it easier to build interfaces? to test the obvious role of things like little languages (DSLs)? If your favored way of situating yourself in reality is statistics, what percentage of the overall effort does this protocol layer represent? Even of an auction app that has no invention, a small fraction. I could bring up a ton of examples off the top of my mind that would have almost no protocol work to them.Does this mean JMock or mocking in general are useless? No. I am offering a counter argument to the preposterous one in the book that makes it seem like JMock was the keystone to the last decade.The best things about this book are: 1. even though it's a narrow one, a book like this is much better using real examples, real code. 2. the concept of the walking skeleton (this is one of the areas of seriously underdelivery) and 3. some of the tips about using static builders, creating test data, acknowledging the limits of mocks, etc.The boldest thing in this book is the concept of the walking skeleton. If I could have coaxed the authors in process, I would have not only told them to make this the centerpiece of the book, but to address the difficulties in being able to really accomplish this in practice. Frankly, if these guys helped us conquer something in the last decade, they ought send out a memo to the Java world, which is more fragmented than ever, and I think everyone would agree, has no grip on the technological underpinnings such a strategy implies (falls down on the first requirement: the ability to perform end-to-end tests). Ironically, one of the reasons this IDEA was so compelling to me is precisely the opposite implication herein: because we have NOT been able to practice this though many of us have wanted it FOREVER!! Did you ever use Cactus? I did. In the bloody beginning. But this is compelling to me now because I have been doing Objective-C/Cocoa programming, and though they don't have this right now, they showed it at WWDC in the form of unit tests for the components and fully functional integration tests in the coming version of Instruments. In summary: the book is attempting to milk an empty utter here, and it doesn't tug very hard or for very long.Do I think this book is worth reading? Yes, absolutely. I look forward to the book that's going to deliver the real promise of the check this one writes itself and then cashes, in any language, on any platform. Hopefully soon..

BOm

Excelente libro para conocer está práctica de programación

This book is a must read for any developer in today's software market. The lessons learned about TDD (Test-Driven Development) are invaluable. Reading this has permanently changed my career for the better.

First of all thanks to the authors/publisher for providing a free access on Safari, because of which I have completed the book in a month.I have previously read Art of Unit Testing by Roy Osherove and also have some experience writing Unit Tests.I bought this book after suggestions from other authors, Stackoverflow, community. I thought that may be I could learn and become a better software programmer, because this book was endorsed me as a deep Object oriented design book. Secondly, I am from a .net background and not from java, so reading those lengthy examples was really a pain.However, I enjoyed reading object builder pattern, Domain Language concept, Window Licker (for Java), some cool tricks by JMock (for java) and hence the three star rating.I have read the entire book page by page, I found that Part 3 to be very lengthy and boring (because of java) whereas other parts of the book are small and I was able to easily grasp from them.

Nachdem "Growing Object-Oriented Software, Guided by Tests" von Steve Freeman und Nat Pryce bei den "Ruby Rogues" besprochen wurde (siehe Episode 68), war mir klar, dass ich es auch lesen musste. Und ich muss sagen: es hat sich definitiv gelohnt. Es ist das beste Buch zum Thema Test Driven Development, das ich bislang gelesen habe.Das Buch beginnt mit einer ca. 70-seitigen allgemeinen Einführung in das (testgetriebene) Vorgehen der Autoren bei der Softwareentwicklung. Dabei wird z.B. TDD erläutert und die eingesetzten Werkzeuge werden vorgestellt. Der Fokus liegt hierbei auf JUnit und jMock.Danach folgt ein riesiges Praxisbeispiel: ein "Auktionssniper", dessen Entwicklung als Java-Swing-Anwendung auf gut 150 Seiten beschrieben wird. Was mir dabei die Augen geöffnet hat, war das Starten mit einem fehlschlagenden Akzeptanztest. Bevor die erste Zeile Produktiv- bzw. Unit-Test-Code geschrieben wurde, haben die Autoren viel Zeit darauf verwendet, einen "End-To-End-Test" zu erstellen, der die erste Funktionalität der Applikation wie ein echter Benutzer testet. Dazu ist einiges an Aufwand nötig (Threading, GUI-Test-Framework etc.), aber das lohnt sich im Nachhinein, weil die Tests mit echten Benutzern entfallen können.Ich muss zugeben, dass ich das Praxisbeispiel teilweise nur recht schwer nachvollziehen konnte, weil ich beim Lesen nicht den ganzen Code im Kopf hatte und immer nur die interessanten Teile gezeigt wurden. Allerdings konnte ich sehr viele Anregungen für meine eigenen Anwendungen mitnehmen, z.B. dass man generische Klassen nicht als Methodenparameter nutzen sollte (sondern besser eine eigene Containerklasse mit einem sinnvollen Namen erstellen sollte), dass einem die "import"s einer Klasse ggfs. verraten, dass diese zu viele Aufgaben hat, oder dass man Factorys besser im Kontext der Domäne benennen sollte (z.B. AuctionHouse anstatt AuctionFactory).Abgerundet wird das Buch durch die letzten ca. 100 Seiten mit wieder eher allgemeinen Tipps zum testgetriebenen Entwickeln. Dabei gehen die Autoren noch einmal in die Vollen und behandeln z.B. das Testen von Multithreading-Applikationen oder den sinvollen Umgang mit Logging-Mechanismen.Alles in allem kann ich dieses Buch jedem Softwareentwickler empfehlen. Obwohl die Beispiele in Java geschrieben sind, lassen sie sich leicht auf andere Sprachen übertragen und jeder Entwickler wird hier eine Vielzahl an Anregungen für die Programmierung mitnehmen können.