A while back, I bought Test Driven Development: by Example by by noted banjoist Kent Beck.
On p. 5, after presenting me with the first code of the book, he writes, “I’ll explain where and how we type it in later, when we talk more about the testing framework, JUnit.” He then proceeds to go on for pages, describing more and more code changes and additions, without ever coming back to JUnit.
Odd.
Still, I decided to keep going. I spent some time getting JUnit set up on my own – Java CLASSPATHs are evil evil evil – and got back to the book a couple of days ago.
It didn’t take me long to realize that even with JUnit in front of me, I wouldn’t be able to follow along with the book. It’s just not written that way. There isn’t anywhere near enough detail provided: what his classes inherit from, how they should be arranged for the sake of later steps, etc.
Now, one of the benefits of TDD as he describes it is its immediacy – you can get to work right away knowing that any mistakes you make will be corrected as you go along. But his book doesn’t allow you to experience this benefit. It just lets you peek in through the window as he experiences it.
Now, JUnit appears to include the example he describes, but it’s the finished example. You’d have to reverse engineer it to get it to the point where he starts his work on it. Basically, you’d have to learn it on your own before you learn it from him. So what do I need the book for?
I’ve heard very good things about TDD from various people, so I will still be giving it a try, but this was a frustrating first experience from a recommended resource.
Weaponized Fluff 