From all accounts, writing a book is hard work. So; fucking props to getting it done Saleemn Siddiqui!
I still wish I could manage it; I've got ideas and I want to share them! But - This ain't about me, it's about
Learning Test-Driven Development
by Saleem Siddiqui
TL;DR
Growing Object Oriented Software or Test Driven Development by Example have a better picture of doing TDD.
Like most other books by skilled developers; it feels like there's a lot of assumptions of pre-existing knowledge and practices projected onto the reader. And for that; it falls short of being a book I'd recommend on TDD.
- Unless asked about it; I doubt I'll open this book again.
The Review
I don't have anything bad to say about "Learning Test-Driven Development". I expect a number of people that do TDD will love it, and find it aligns with them fantastically. ... While I don't have anything bad to say, I don't have anything great either. It does some stuff I'm not a fan of and I think lends itself towards bad code and TDD being harder to do in the long run.
It follows what TDD By Example does but... less talking about the refactoring and why certain changes. It's more of a "here's the mechanics how to do it in these three languages". If you want the why's - go get TDD by Example. Which... unless you need a book to learn to do TDD in one of these 3 languages; go get TDD by Example.
There's some stylistic elements that I don't agree with, which drags down my view of the book. I love me some OOP, and this book ignores, or misrepresents why certain good OO practices are done.
The biggest "no, no, no, no" is that advocation of puttting MULTIPLE NEW classes into a test to "go faster". Yes... It'll sure make it feel like you're going faster... until something screws up and you spend time debugging instead of having many small tests to prove out each concept; which you then refactor away (if you so choose) on green!
Literally calling out multiple DOES NOT EXIST YET objects. This feels like it leads to "do whatever in the test, make it all work, then do it again".
I think this is stylistic of outside-in inside-out style of tests (place for both), but it doesn't drive generation of higher quality code when done like this. You can write a single test and WHATEVER for the implementation. It's a reason I disagree with just "end-to-end" tests in a system. It says nothing about, and does nothing for the code as a whole. You'll hit pain to make changes.
The very first test in the book has multiple concepts. I'll blame Kent Beck for this, as TDD By Example has, essentially, the exact same first test.
There is some small stuff with hard coded values. I really like breaking apart the value into the reasons for it. Like in FizzBuzz, when we change 15 into 3*5.
This book completelty bypasses and never talks about triangulation. I consider that a HUGE value of TDD. You keep writing tests until it forces you into a generalization. After a while, and for simple things... SURE. But no. You start skipping, you'll start slacking... and I feel that this book gives guidance to shortcut.
Some changes, which are nice to see, are not explained other than it makes testing easier. But... That's not the goal. That's not the reason. It's a consequence of making a good design decision; not the reason to do it!
A class is added w/o actual need. It's just; We'll need X, and Y, and Z, as well as W to do what we want. Here's a test using THEM ALL... It's not needed, it's forced in.
While I'm vatly against this type of big bang approach to introducing new concepts; the amount of time you're going to be in the red - That test is gonna be red for a while; and if you make a goof - a long while.
Introducing MULTIPLE ENTITIES in a single test is teaching people to operate in a way that's going to lead them into a disaster, and it'll be easy to blame TDD.
... It's not horrible, but I think there are better books for someone new to TDD.