I’ve had this book on my bookshelf for around 6 years, but for some reason, I’ve only decided to read it this year. I’m not sure why it took this long. But I’m happy I waited all this time, as I feel like I wouldn’t have had the same experience 6 years ago.

Most developers I know tend to focus too much on HOW they do something, but they rarely think about the WHY. They love to show all tricks they can perform in many different languages and tools, but when you ask them why they did something in that way instead of some other, you will probably not get an answer. I’m guilty of this myself. It took me a really long time to learn that focusing on the WHY is way more important than knowing how to do something. “Test Driven Development by example” is more of a book on WHY you should practice TDD instead of HOW and, had I read it 6 years ago, when I was still a “how-developer”, I would probably get disappointed.

The book is mainly split into two parts. In the first one, we have two chapters showing how TDD can be applied in practice. The first chapter shows this by applying the practice to implement some code that can handle some basic operations on multiple currencies, while the second one does the same with a basic implementation of a xUnit test runner. The second part is basically a complement of the first one, with a few chapters going into the details of some of the patterns applied in the first part, and some other talking about TDD in general in a QA format.

While the first part might sound a lot like a “HOW” kind of book, there’s actually a lot about “WHYs” as well. The author constantly reminds us of the advantages of designing your code using tests. Clearly, the main one is to be able to focus on one single and small problem at a time. In the book, this is demonstrated by using a small to-do list. Whenever the author needs to implement something, he starts by creating a to-do list based on some initial assumptions of how things should work. He then starts from the one he thinks it’s the easiest to implement, and, using baby steps and the red-green-refactor cycle, focus only on that exclusively. Once that is done, he does the same with each one the other. Sometimes, during development, he will realize that something about how things should be implemented. Something different from his original assumptions. When that happens, he simply adds that to the to-do list and keeps on focusing on the problem.

Another important advantage of TDD that is demonstrated multiple times is how it gives you control of the step size. Baby steps are one of the first things you will hear when you start learning about TDD. The idea is that you should always implement the simplest possible solution that makes a test pass, even if it makes you write something like this:

// Test
function testAddition() {
    assertEquals(2, add(1, 1));
}

// Implementation
function add($a, $b) {
    return 2;
}

Even though this is mentioned in the book, the author emphasizes that is totally ok to take larger steps when you feel more confident and/or is able to see an obvious implementation. In fact, the author mentions that he finds himself constantly switching between baby and larger steps while test driving, all based on how confident or anxious he feels about the code.

In this post on Facebook, Kent Beck, the author of the book, lists a few other WHYs, or problems, that TDD helps you solve.

Six years ago, I would expect this book to show me HOW to write tests and would probably get really disappointed as it only shows some very basic examples, far from what I write on a daily basis. It barely mentions things like mocking, for example. However, if you’re like me nowadays, and the WHYs are what interest you the most, this book can still be interesting.