Slashdot Mirror
Test-Driven Development by Example
What it's all about: Test-driven development is about being able to take tiny little steps forward, test that the step took you in the right direction, and repeat. The "TDD Mantra" is red/green/refactor:
- Red: write a test which will exercise a feature, but which will fail (because you haven't yet written the code)
- Green: make the test succeed, doing whatever you need to do to get to "green" as quickly as possible -- don't worry about prettiness
- Refactor: now that you have code which passes the test, eliminate all the duplication
The book then shows 2 fairly detailed examples of a development project (or snippet of a project) which progress using this style of coding. The first example deals with the creation of multi-currency capabilities for an existing project. In the space of 17 chapters, the author walks you through the creation of 6 classes (1 test class, 5 functional classes), complete with the thought-processes behind them. The code is written in java, and is trivially easy to follow, because it gets introduced in tiny little chunks; most chapters are less than 6 pages in length.
The second example is the creation of a unit testing framework in Python. It is significantly more complex and real-world than the first example, but again proceeds in very small steps, and in small chapters.
The final part of the book contains patterns for test-driven development -- practical real-world advice on how to do this stuff for real. Nearly all the "patterns" are phrased as question/answer pairs, and they range from deeply technical design patterns to advice on the best way to arrange the furniture.
What's good about the book? Kent Beck is a very good writer -- his writing is clear, he is not afraid to leave out stuff he assumes you can guess for yourself, but when he does go into detail you feel it is necessary to get the big picture, rather than mere geek bravado. Even if you don't adopt Test-Driven Development, many of the ideas are well worth considering for your day-to-day coding situations.
What could have been better? The book stresses the importance of taking 'little steps,' and sometimes you feel impatient to move to more challenging tests before properly finishing the current chapter. I was also hoping for more of a discussion on the practicalities of unit testing database-driven systems, where you frequently have to test business entities which are closely coupled to the database.
Summary If you code for a living, or manage people who do, you should read this book -- it's a quick enough read -- and consider some of the assertions it makes. If you feel you're introducing more bugs than you expected, if you feel uneasy about how close your work matches the requirements, this book gives you some powerful ideas. You can purchase Test-Driven Development by Example from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
In my experience, extreme programming was invented by/for programmers who hate designing and discipline, and just want to start hacking. It leads to sloppiness and half-finished code, and it's not a scalable approach for large projects. I had the misfortune of having some guys on a project who insisted on working this way, and we had a huge mess to clean up in their wake. I'm glad this programming philosophy seems to be dying out.
First of all, note that I'm not knocking the principles of Extreme Programming (XP).
The first XP book written by Kent Beck reads like a self-help book. If you're going to write a book whose principle is "feel good about yourself," and you're trying to fill 200 pages, then you can't just cut to the chase. You have to ramble on for a few chapters about what you're going to say, and slowly let out bits of information here and there, then there are chapters the reiterate what you've already said. Beck's books--and all of the books in the XP line that I've seen--read the same way. You could explain XP clearly and concisely in a few pages, but the XP books go around and around in cicles, and after a while you're not sure if you're getting new information or not. And, miraculously, the XP line has been extended to six or more books, each of which goes over the same small bit of information in another verbose and rambling way. There's even a book about XP critcisms, which is an officially sanctioned book in the XP series, which exists simply to reinforce the basic principles of XP.
The whole thing smacks of books like Dianetics or various lightweight volumes from self-help gurus. If there was any meaning to XP, it has been lost in endless self-justification. Imagine an entire series of books that did nothing but tell you how cool Linux was. What's the point?