Burk on Books: Growing Object-Oriented Software, Guided by Tests

If you want the short version, here it is: Developers should get this book and spend some time absorbing the ideas in it. It’s well written and easy to read, but grokking it all will take time and practice. I recommend doing it as a team, book club style; read a bit then discuss it so you can bounce ideas off each other and get the benefit of other viewpoint. I also recommend starting now so you can write better code sooner!

Note to those who care: ‘Grok’ is a real word now, it’s in the Oxford English Dictionary, though I prefer the definition in Merriam Webster’s.

Still here? Well then, I think it’s safe to assume one or more of the following; you weren’t convinced by my four sentence review, you want more details about the book, or maybe you’ve just got some time to kill and like my writing style. Hey, stop laughing, it’s possible...

According to the authors, “Growing Object-Oriented Software, Guided by Tests” is the results of a couple of decades of experience, including almost ten years of Test-Driven Development (TDD) on a wide range of projects. While the authors state that the goal of the book is to teach you TDD, don’t believe them. From what I read, the goal is to teach you TDD the way it should be done. Just as having 100% code coverage doesn’t mean there are no bugs, writing unit tests first doesn’t guarantee a working system.

The authors expand upon the traditional approach to TDD by adding acceptance tests to the mix. Acceptance tests, sometimes called end-to-end tests, begin at the user level (UI or public API) and exercise all parts of the system to ensure the system performs correctly.

Their approach adds an outer loop to the standard Red-Green-Refactor cycle. The loop starts with writing a failing acceptance test then writing all the unit tests needed to make it pass. While it may seem to be a small thing, I think adding the outer loop gives needed direction to the developers’ efforts by highlighting what should be built next.

The book starts with a quick introduction to the authors’ view of TDD, the tools that will be used in the examples throughout the book (JUnit 4, the Hamcrest matching framework, and the jMock2 Framework).

In Part II, the authors go deeper into how they start a project using their acceptance test/unit tests approach. In it, they introduce the concept of a “walking skeleton” which forms the basic structure the rest of the system is built upon.

Part III, a “Worked Example” is the longest section of the book, and it’s where we get to look over the authors’ shoulders as they build a nontrivial application that includes a Swing-based user interface and third-party services in the back-end. Even so, it’s not a realistic application, which is good because at the level of detail they’re giving us, the book would be too big to lift.

One of the most important things this book does is prove that you can test-drive a functional user interface. Yes, it’s a Swing-base UI, but I suspect you could follow the same approach using Seleium or Geb and test-drive a web-based UI too.

Part IV is titled “Sustainable Test-Driven Development” and it the authors present some useful guidelines intended to help you keep your sanity while maintaining a test-driven approach.

Part V covers “Advanced Topics” like how to test persistence, dealing with mult-threading, and how to test asynchronous code.

There’s more after that, including “A Brief History of Mock Objects” and two useful Appendices.

I said it before, and I’ll say it again. Developers should get this book and spend time absorbing the ideas in it; preferably with other team members for the most benefit, Go solo if you must, the time invested will be well spent.

Disclosure: I received a free copy of the book from the publisher, with the understanding that I would read it and write a review of it. For more information read my Full Disclosure post.

Here's the publishing details:

Title: Growing Software , Guided by Tests

Authors: Steve Freeman and Nat Pryce

Published: 2009 by Addison-Wesley

ISBN-10: 0321503627

ISBN-13: 978-0321503626

Full Disclosure on Book Reviews

It seems I may have some housekeeping to do so please read this posting so you'll know what to expect from my book reviews.

Some time in 2009, the FTC published guides governing endorsements and testimonials that may apply to me. While I do buy some books and review them, most of the reviews I post are for books I have received from the publisher with the expectation that I would read the book and post a review. Please note that I said "a review" and not "a positive review".

If you read my reviews, you'll notice that they're all pretty positive. There are multiple reasons for that, but I want to make it clear that other than the book being reviewed, I do not receive any kind of compensation from any of the publishers, or anyone associated with them, in exchange for a positive review. Note that I have, on occasion, asked for copies of a book to give away when doing a presentation at a developer conference. I don't see that as compensation because it doesn't benefit me so much as the people who get the free books.

There are two main reason my books reviews are positive is simple. The first is that I'm not vain enough to believe that if I don't like a book then it must be a bad book. The second reason is because before I ask for a review copy, I do some research. I'll look for the book on Amazon or Safari, or even in a real book store, and read a bit. If it looks interesting and I like the style then I'll ask the publisher for a review copy.

If I'm reviewing a book that's just come out then it's likely I've either read a previous book by the author, it's part of a series (like Head First) that's earned my trust, or it's a topic (like automated testing) that I'm deeply interested in and am willing to take a chance on the unknown.

In case you're wondering, I tend to like books that are technical without being dry. The author should present the information in a way that doesn't make me feel like they're looking down on me because I don't already understand whatever they've spent a decade mastering. Good examples include Presentation Zen, PragProg books like Pragmatic Thinking and Learning, and anything in the Head First series published by O'Reilly.

By the way, Addison Wesley sent me some books that are definitely top notch. I just posted a review for "Essential Skills for the Agile Developer", I'm writing the review for "Growing Object-Oriented Software, Guided by Tests", and I'm reading "12 Essential Skills for Software Architects".

Setting up all those links reminds me, while I often provide links to Amazon, or a publisher's site, so you can easily buy the book being reviewed. They are for your convenience only. I don't get credited or compensated for purchases made by folks using those links.

In the spirit of full disclosure let me say that I once requested a book from a publisher and, after reading it, realized I couldn't give it a positive review. The book was a certification guide, but there were so many factual problems that I knew I could not recommend it to anyone. Instead I emailed the publisher a rather long list of the errors I found, let them know I could not publish a positive review, and offered to send the book back.

So, that's the story. Many of the books I review are sent to me at no cost, but with the expectation that I will read them and post my honest opinion. Some of them are books I bought and wanted to share with you. In either case the opinions I post are mine and are as objective as any opinion can be.

Burk on Books - Essential Skills for the Agile Developer: A Guide to Better Programming and Design

“Essential Skills" is a part of Net Objectives' Lean-Agile series. The authors’ intent is to teach the "minimal set of skills developers need on the journey toward becoming adept at incremental development.” In my opinion they’ve more than met that goal.

Note that while the title says "Agile Developer", almost all the examples are in Java, and the skills are just as useful to Java developers as to any other kind.

Due to its focus on the fundamentals of good software development, “Essential Skills” is one of those rare books that is valuable to both beginners and experienced developers.

Beginners will learn to develop high quality software, while experienced developers will be reminded of valuable practices they may have dropped while attempting to meet aggressive deadlines. But there's more.

The authors also describe the benefits gained, which is quite useful if you're often asked to "cut corners" and deliver something sooner. (Imagine flashes of lightning and ominous music here.) Once business people see how rushing things out the door leads to lower code quality, and eventually results in longer deliver times, they tend to back off a bit.

You've no doubt heard that moving a team that produces so-so software to an agile process won't improve the quality. They'll just produce it faster. However, using the skills you learn from this book will increase the quality of your software. And, over time, you may notice that it's sped things up too - whether you go agile or not.

In short, I strongly recommend this book for both beginning and experienced developers, no matter what methodology you follow. I found myself nodding in agreement more than a few times as I read, and I think you will too.

Oh, yes. One more thing. If you do nothing else, find someplace to read the Preface. Yes, that's right, the Preface. It's only two pages, but there's something worth learning right there. If you're not sitting in a bookstore, you can get it straight from the publisher at InformIT. If the link doesn't work, just go to http://safari.informit.com/9780321700469 then click the link for the Preface and enjoy.

“Essential Skills for the Agile Developer: A Guide to Better Programming and Design”
Authors: Alan Shalloway, Scott Bain, Ken Pugh, Amir Kolsky
Publisher: Addison-Wesley Professional; 1st edition (August 29, 2011)
ISBN-10: 0321543734 ISBN-13: 978-0321543738