Beck K., TDD by Example (2002)

The foundational book on TDD. As mostly conceptual, it is an interesting reading for the experienced TDDers. The TDD cycle is, probably, the sole practical - yet critical - takeout for beginners.

Summary

Despite being foundational, the book is organized a bit chaotically — as other Beck's books are, as maybe many things are at the beginning.

The book contains 3 parts: "The Money Example", "The xUnit Example", and "Patterns for TDD". It presents toy-like examples mixed with notions from other independent parts of SWE that bury the hard-to-infer basics.

This, I suspect, made TDD much more difficult to absorb. The book will reveal a little more value when you practice TDD long enough to discern its interesting bits from filler and biases.

Core Concepts

TDD means "write test first, then write code to satisfy the test". Here is the core TDD technique known as Red/Green/Refactor:

• Red: Write a small test that obviously fails in absence of code it tests;
• Green: Make the test pass quickly by writing the code; the code can be imperfect;
• Refactor: If necessary, clean up the code introduced in the previous step.

Now return to Red by adding another test that fails. This is it.

Benefits

TDD leads to a dramatic reduction in code defects when applied correctly. It also makes easier new engineers onboarding due to tests acting as the code usage examples and the early deliverable of the living documentation.

Besides, when paired with DDD Ubiquitous Language ¹, it provides the domain knowledge for non-tech team - customers, business experts, product managers (product owners) etc. That, in turn, leads to product value improvements.

Issues

"Writing test first" leaves the reader questioning how to know what to test. The book dismisses what it calls "traditional upfront" software modeling and code design, and in replacement proposes vague "organic design". That misleads an engineer producing software that delivers customer value.

Then the book introduces the "paradox—test the program before you write it".

However, it looks like a "paradox" only because, intentionally or not, the "traditional upfront" design is replaced by the vague "organic design".

The paradox (and the "magic" of TDD) suddenly disappears when you approach tests with the code model (design) at hand: participants (objects with meaningful names—we speak OOAD ² here), their responsibilities, inputs, outputs, states, and relations.

The flow now becomes clear without any magic: requirements → model (design) → test → code.

Here I conclude the review, as the core ideas and concerns are all laid out.