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.
Although it sucks to lose 20% of your code when you drive it off the lot.
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
I don't like ESPN's eXtreme Programming, but now that the NFL is over, I don't have much of a choice.
...been doing this for years anyway? My code development cycle has always been... 1. Write code to use function/procedure. 2. Write function/procedure. 3. If function/procedure==fucked return to 2 and unfuck. 4. Once it works, tidy it up. Now it appears someone else has added steps 5 and 6... 5. Write a book about it. 6. Profit!!!
What would Dilbert do?
Here and here!
I love buzzwords with X anyway..."There is no teacher but the enemy."-Mazer Rackham
The RIAA issued a press release saying that they are initiating a lawsuit against Kent Beck because eXtreme Programming principles could lead to faster development of file-sharing software. The RIAA's main argument is that CD sales are falling at levels that could only be explained by eXtreme Programming.
That's why I've moved on to XXP, which focuses first on correctness of tests. First, I write a test that tests a test. Then I write the test. I test the test until the test tests ok. Then I write a test for another test, and so on.
My pair programming partner is currently working on an idea he calls "XXXP". I'll post our results if we ever finish a project without getting lost in infinite recursion.
Lucky! Had the buzzword bingo won out, they'd replace you with 12 hard-working yet inexpensive immigrants. Of course, the 12 immigrants wouldn't produce any results faster or better, but they sure look busy! And the respect the boss gets! Those immigrants sure know how to run around and bow to the boss! Run! Run! Or I'll call the INS!