Personal Preface: It has been a long time desire of mine to work through the ideas found in Steve Freeman’s and Nat Pryce’s Growing Object-Oriented Software, Guided by Tests. My hope in blogging about my reflections is that it will aid the educational process and allow you to join along with me. My intentions are to faithfully distill and express the authors’ understanding of how object-oriented software should be written using tests.
————
I’d like to begin our mini-series with the book’s Preface as a means of providing foundation:
1. What is this book all about?
2a. Why “growing” object-oriented software?
2b. Why “guided” by tests?
3. What was the motivation behind the book?
What’s this book all about?
In the words of the authors, “This book is a practical guide to the best way we’ve found to write object-oriented software: test-driven development (TDD).”
The book is a “practical guide” to writing object-oriented software using test-driven development, and being a “practical guide”, we will not be surprised to find very opinionated views contained therein on how we should and shouldn’t right object-oriented software. To be clear and so that we are fair to the authors, we will accept their premise that test-drive development is the best tool in achieving that goal. That being said, I do, however, hope you’ll come to find the tremendous value that is test-driven development while practicing their techniques.
It is also worth noting, (perhaps as a foreboding warning) that people could possibly walk away doing “the raw practices (writing and running tests) but struggle with the result because they haven’t also adopted the deeper processes that lie behind it.” And thus, it will serve us greatly to keep a close eye out for “how [their] approach to design informs [their] approach to TDD“. It’ll be one of our goals to flesh out these “deeper processes” and their approach to design.
Why “growing” object-oriented software?
The word “growing” suggests an incremental view to development with a biological quality. It will also be helpful to have a working mental model of biological cells for understanding object-oriented programming while reading the book. The authors make reference to Alan Kay, one of the fathers of the idea of object-oriented programming, when he compared objects to “being like biological cells and/or individual computers on a network, only able to communicate with messages”. We will return to this useful simile and try to gain more insight into how message passing plays a role in their understanding of object-oriented design.
Why “guided” by tests?
Tests are said to best guide the development of our object-oriented software when we write them first. In doing so, they can “guide” us in three ways:
- Writing tests helps us understand our current intentions and helps us understand what we need to do next.
- Secondly, and more interestingly, the process of writing our tests becomes a “design support tool“. It’s important to understand that by themselves, tests will not design your system for you. Tests are a tool that can give you the ability to detect where your software design may have gone wrong if you are, as the author likes to put it, “listening to [your] tests”. What is it then that we should be listening for? A lot of what the book has to teach us is in regard to knowing what to listener for in our tests so that we can improve the design of our software. And like any other tool, our ability to listen to our tests will require skill and experience.
- Whenever we find ourselves needing to fix our design after listening to our tests, the tests will let us know if we have broken anything in the process of making changes.
What was the motivation behind the book?
Underpinning a lot of the authors’ design decisions comes from their interesting opinion that the domain model of the system shouldn’t be found in the objects themselves, but in their “communication patterns” and in their composition. In 2004, the authors of our book presented a paper entitled “Mock Roles, not Objects” [1]. We will refer to this paper quite a bit as we move through the book but it seems that one of the motivations behind the book was to also illustrate how mock objects fit into their larger understanding of building object-oriented programs guided by tests. We will spend a great deal of time exploring the implications of this opinion in future posts. The important thing to understand, for now, is that one cannot understand their intended use of mock objects (a testing technique which we will delve into in a future post) without understanding the author’s belief that the “communication patterns between objects are more important” than the class structure themselves.
Up Next
For our next post, we will try to get a working understanding of the book’s structure as we spend some time in the book’s Table of Contents and the book’s sub-headings in order to construct categories to hang our findings. Stay-tuned!
In Conclusion
The book will teach us how to best utilize test driven development for the aim of designing good object-oriented software.
