Growing object oriented software guided by tests - notes

Last updated Nov 27, 2021

Test driven development has been a subject of interest on this blog for a few years now and the first pot to come around was the classic book from Kent Beck: Test Drive Development by example. More recently I also wrote on my TDD journey as I was trying to focus on what would be the next steps on that.

Following this discovery, I started reading the book “Growing object oriented software guided by tests” [1] which as the title says focus on the development of software guided by tests, more specifically the proposal is to use a double loop TDD.

If I were to give a comparison between TDD by example and GOOSG I would say that on one hand, TDD by Example, focuses on shifting the mindset for testing code, approaching simple problems in a way that start with test first. On the other hand, GOOSG focus on expanding the mindset for applications end-to-end.

The notes in this post are just my thoughts around the GOOSG book and also questions that came up during the process. Enjoy!

Part I

The first part of the book dives into the TDD flow to give a common ground for the reader and also for the authors to build on basics before getting the book subject in place.

In this first part the Red-Gree-Refactor [2] is introduced as well as the idea of feedback and practices that support change. The book is from 2009 and the agile mindset was already in place, business move fast so we should adapt accordingly. Feedback is fundamental to support this mindset, TDD give developers the way to move forward fast and with confidence.

Steve and Nat also worked on a brief introduction on junit and jMock, this is the foundation needed to at least get started with testing. Despite of the great introduction in the book, chapter 3 is the most basic needed from the tools. There are other books that gives in depth explanation around junit, hamcrest and mocks. All in all, I felt that it was in the book as a requirement, in the end, would be difficult to start writing assertions and mocking things out without at least a minimum understanding.

Part II

Coming soon

Part III

Lastly the idea of end-to-end tests are introduced as a practice that we should implement as a means to mock how the user will interact with the application.

For this first part, the idea of end to end tests is the one that carries (at least for me) the book idea. The title makes sense to me as the test is part of the development cycle not just for specific parts of the system but for everything. This idea is elaborated in details in this part when the authors talk about a walking skeleton.

A common practice is to call this step iteration zero: “iteration” because the team still needs to time-box its activities and “zero” because it’s before functional development starts in iteration one. One important task for iteration zero is to use the walking skeleton to test-drive the initial architecture.

Growing object oriented software guided by tests, Steve Freeman and Nat Price, pg 83

In my opinion, the walking skeleton is the most important bit for any application that is developed in a testing oriented fashion. The skeleton is the foundation in which the project will be build on, in other words, this is an architectural decision that makes clear that every bit in place is designed for testability. Not ont at the unit level, but also having a look at the application working as a whole.

We’ll start by writing the test as if all the code it needs exists and will fill in the implementations afterwards.

Growing object oriented software guided by tests, Steve Freeman and Nat Price, pg 85

Besides that I would like to elaborate on the following bullet points extracted from the book:

  • Acceptance: Does the whole system work?
  • Integration: Does our code work against code we can’t change?
  • Unit: Do our objects do the right thing, are they convenient to work with?

Acceptance testing has different understanding from software practitioners and testers, as mentioned in the book, acceptance should be as end-to-end as possible. From my understanding, end-to-end means to use whatever dependencies needed, for instance: the database, a websocket server, cache server and so on. Earlier on this blog I wrote about strategies to test legacy code that goes towards this goal, there I mentioned the test pyramid as a way to give to measure how to start writing the acceptance test then moving downwards the pyramid to reach the unit tests.

Now reading GOOSG, I see similarities around the approach I wrote and the one they offer, in the next section, the XMPP server is an external dependency that it is used on the acceptance test. For me the clear message that this part gives is: feedback on the entire system is important and we should aim to work on that early on. Faster feedback means quicker response to change and adapt if needed. Exercising the system end to end is a way to achieve that.


  • I found one thing that is interesting to link, this github project that recreates the auction system step by step via commits.
  • This blog post is kinda a good sum up of the book, besides that the author also gives his point of view and the “the bad parts” about the book. I think that this post could be a reference for people that don’t have time to read the book.

A note on outside-in TDD

When I am coding, usually I prefer the London school. Practicing outside-in TDD is my go to for any exercise or professional work. I even built an json-tool that uses outside-in with cypress + react testing library. Anyways, it wasn’t before I gave GOOSG a read, that I started to ask myself, was GOOSG book the precursor for the different schools of TDD?

Such question came up, as I went by the book and saw this statement:

This slice is so minimal that we’re not even concerned with sending a bid; we just want to know that the two sides can communicate and that we can test the system from outside (through the client’s GUI and by injecting events as if from the external auction server).

Growing object oriented software guided by tests, Steve Freeman and Nat Price, pg 84


  1. [1]S. Freeman and N. Pryce, Growing object-oriented software, guided by tests. Pearson Education, 2009.
  2. [2]K. Beck, TDD by example. Addison-Wesley Professional, 2000.