Growing Object Oriented Software Guided by Tests — TLDR
When I first joined Wix as a Software Engineer, I heard about the book Growing Object Oriented Software guided by Tests by Steve Freeman and Nat Pryce (which is referred to as the GOOS cause it’s official name is oh-so-long). In this series of posts, I will be summarizing the main chapters of the book.
Basically the book is about TDD (Test Driven Development). Everyone who’s read the book says it’s a must-read, and I know that when I read such technical books I enjoy them but I can’t remember the bottom lines cause these books are just so so long. Also I figured more people who can’t find the time to read them through will appreciate any TLDR of such a classic book.
If you do want to read the whole thing, here’s a link to purchasing it.
If you wanna just read the bottom lines, keep reading this series of blog posts :)
Ok, let’s start! We’re going to drill right into the first chapter’s summary.
Chapter 1 — What is the point of Test-Driven Development?
The Golden Rule of TDD:
Never write new functionality without a failing test.
“…You have nothing to lose but your bugs”!
We’re going to dive right into the main terms of the first chapter:
Coupling — Elements are coupled if a change in one, forces a change in the other. Loosely coupled features are easier to maintain.
Cohesion — An element’s cohesion is a measure of whether its responsibilities form a meaningful unit. It should represent a whole concept and not contain any unrelated concepts.
Internal Quality — How well the system meets the needs of its developers and administrators. It should be easy to understand and easy to maintain. It lets us cope with the unanticipated required changes. The internal quality is controlled by unit tests.
External Quality — how well the system meets the needs of its customers and users. The external quality is controlled by end-to-end tests.
Software Development is a learning process, and Feedback is the fundamental tool. If one discrepancy slips through an inner feedback loop there’s a good chance an outer loop will catch it. Some trivial feedback loops are: running unit-tests and integration tests. Personally I like to think of some more feedback loops in the software industry like doing Daily meetings (where you say what you plan to do and report back the day after about it), Sprint Retrospectives (what went well, what needs to be improved? That’s an outer feedback loop), etc.
Let’s consider 3 levels of tests;
- Unit tests
- Integration tests
- End-to-end tests.
Unit tests give us feedback about the internal quality of our code.
End-to-end tests give us more feedback about the external quality of our code.
Right in the middle between unit and end-to-end tests, we have integration tests, that give us feedback about both the internal but also about the external quality of our code.
One of main ideas in this book it to have an incremental and iterative development process:
We can’t deliver the whole project when it’s done, that’ll take months. We have to get a “slice” of it to work, and then deliver that slice.
My Favorite Quote:
“Music is the space between the notes”. — Clause Debussy. As comparison, Object-oriented design focuses more on the communication between objects than on the objects themselves.
Yay! we’re now on page 37 of the digital version of the book!
