Test-Driven Development by Example

PinglePongle writes "Kent Beck is well known as one of the main drivers behind eXtreme Programming -- a style of development which favours a very disciplined but low-formality approach to coding. Writing applications 'test-first' is one of the practices of XP, and this book explores the subject of test-driven development in detail." Read on for the complete review. Test-Driven Development by Example author Kent Beck pages 220 publisher Addison Wesley rating Superb reviewer PinglePongle ISBN 0321146530 summary Kent Beck -- author of the original Extreme Programming book -- explains in detail how to turn your development world upside down by starting with the test, then writing the code.

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.

Comments

What the XP folks have right (and wrong)

[thac0]

The reason some XP projects are successful is because they actually have testing as part of the game plan. It is *shocking* to me, having been in the industry for better than a decade and pounding code for 20 years, the state of testing in corporate america. Just atrocious.

There are many labs that don't test at all, and a vast majority test poorly. I've worked in some fortune 500 labs that didn't test at all. Scary stuff. Nothing life threatening, but all of a sudden I wasn't so convinced that the reason my account was misconfigured was because *I* gave wrong data. Simply bug riddled. Those that do test often do so manually. Forgetting for a moment that humans are likely to take short-cuts and not bother to execute tests they perceive to be out of the scope of their recent change, they are failable. Of course they are, that's how the bugs got there in the first place.

So, the XP folks have the testing thing down. They test before the code is written, and their tests are automated.

Then they take leave of their senses. The claim that because they've successfully turned one idea on it's head (i.e. testing *first*) that they can turn others is ludicrous. Design first is still valuable guys. I've eliminated thousands of bugs simply by having the right design to begin with. Waiting until you've cobbled something together that passes the test and then hoping that your boss will allow you to refactor is a loser. If it weren't Scott Adams wouldn't be a millionare.

So, write your tests first. But do your design before you code, not after you've put together a thousand lines of crap.

Re:What the XP folks have right (and wrong)

[Lumpish Scholar]

... some XP projects are successful is because they actually have testing as part of the game plan.... the XP folks have the testing thing down.

The best thing about XP is that, with the possible exception of test-first (a.k.a. test driven) development, none of the practices are new and original. I mean that in the best possible way! All the practices are tried and true, based on experience long before Kent Beck was using the word "extreme" this way.

Then they take leave of their senses.... Design first is still valuable ...

"Design" in the pure waterfall sense -- do 100% of the requirements before doing any of the design, do 100% of the design before doing any of the coding -- doesn't scale up to large projects or rapid development. It's important to use an iterative approach: do a little analysis, do a little design, do a little coding, do a little testing, repeat until done.

XP breaks the design/coding/testing cycle into very small iterations, each one as big as one automated unit test case. It's a very exploratory style of software development. XP doesn't mandate any high-level design artifacts (though it doesn't forbid them either).

What none of the XP books say is that developing unit tests is a design activity, and the unit tests are design artifacts! Unit tests outline the responsibilites of classes, in the original responsibily-based style of object oriented design.

XP programmers do design on whiteboards, and in their heads. Some of these artifacts are lost. Some would have become obsolete in a hurry. (The unit tests are guaranteed not be obsolete, at least as long as they're passing.)

I'll take that, any day, over a hundred pages of out-of-date UML diagrams.

Re:sounds great but...

[Lumpish Scholar]

I just can't stand other people nozing around in my half completed code ...

Then you ought to (1) try the other XP practices before you try pair programming, and (2) learn how pair programming really works!

... the extreme attention to testing ...

You don't think testing is important???

... and the team-spirit you ought to have ...

Check out the work of James O. Coplien. He's an extremely hard core C++ guy, but when he was doing research at Bell Labs, he descovered that organization effectiveness was far more important for software development productivity than any technological advance.

I once worked at a start-up where someone started on Monday, and never came back after Wednesday night, leaving a voice mail message that said, "You never told me I was going to have to work with other people!"

You're going to have to work with other people. The better you work with them, the better you work, the better everyone works. (Hugs not required.)