I like Test-Driven Development (TDD). It's a great idea to use tests to guide you through your development process. Just like the idea to end your day with a failing test. That way you have an awesome starting point the next day.

In my previous job as a .NET developer, TDD was a familiar tool for me. The IDE, the libraries I used, and all the other things around that did their part to make testing a breeze. With my change to iOS development, a lot of stuff changed for me. Xcode instead of Jetbrain Rider, Swift instead of C#, XCTest instead of Xunit, etc. And, while unit testing was at the top of my TODO list while transitioning to iOS development, getting familiar with everything so that TDD feels natural again wasn't a top priority for me. And I felt now was the time to fix that. So I read "Test-Driven Development in Swift" by Gio Lodi.

Is it a good book?

I think it is. The author shows how to develop an app in an iterative way using a test-first approach. He also uses a single example app and sticks with it for the entire book. I like that. And yes, I said "test-first approach". I did not say TDD. I did it on purpose. 😄 But before I get too critical: If you are looking for a book that shows you how to write and use tests to create an app, this book is for you.

So why "test-first" instead of "TDD"?

TDD has rules. Depending on your favorite author around this topic they might differ a bit. But some things will always be the same. For example: You will always start with a failing test. The "red"-phase inside the "Red -> Green -> Refactor" cycle. That's the first rule of TDD. And most of the time the author sticks with it. Except when he doesn't. 🤷 And when he doesn't, I don't understand why. In every scenario I remember, it would not have been too hard to write a failing test for the planned change.

I hope this does not come off as gatekeeping. I don't like gatekeeping. I hate it if discussions start with the phrase "You are not a real xyz if you...". But the author is selling a book about "Test-Driven Development", at least that is what the title says. Maybe the simple reason is that books with the term "Test-Driven Development" in the title will sell better than books with "doing test-first most of the time". 🤔

With the correct expectations, you will enjoy that book

But again, I'm not saying that this is a bad book. It's not. But set the right expectations before reading it. If you want a book that gets to the core of TDD, go with Kent Beck and his book "Test-Driven Development by example".

For me, the book was still useful and I learned quite a bit while reading it.