Growing object oriented software guided by tests - notes (WIP)

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 step-by-step guided by tests.

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.

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.

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 elaborate in details in the next part when the authors talk about a “walking skeleton”. 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. Ealier on this blog I wrote about strategies to test legacy code that goes torwards 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 depedency that still it is used on the acceptance test.

Part II

Coming soon

Part III

Coming soon


  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.