Test-Driven Development: By Example - one great tip, not much else

Had some interesting points, but overall this one wasn’t worth the read for me. 2/5.

The problem is where I was coming from. I’d already been doing TDD for my job for years, and I picked this up wondering if there was something else to learn, to make sure I was doing it right. Turns out there wasn’t much. The worked examples had little new to show me, and nothing in the book clashed with how TDD works in my real job. It mostly confirmed things I already do every day. The asides on the philosophy of TDD were the part I actually enjoyed.

That said, the book did give me one tip I really liked. When coding your own project, always leave a coding session with a broken test, so next time you start you jump right back in to where you were. It’s adapted from the writing advice of always finishing a session halfway through a sentence. I’d never heard of it before, and at the time I wrote that I was immediately going to start using it. Honestly, though, it didn’t stick. I used it for a few months, but when you work in a team you really want your work totally done before you finish up.

So who is this for? Not experienced TDD practitioners, we’re clearly not the audience, and the examples will drag. And I wouldn’t hand it to beginners either. If you’ve never done TDD, just watch YouTube or read some blog posts and try it out. If one tip and some philosophy asides are all a book leaves you with, it’s hard to call it worth the time.