Test Driven Development By Example

Write clean code that works with the help of this groundbreaking software method. Example-driven teaching is the basis of Beck's step-by-step instruction that will have readers using TDD to further their projects.

Kent Beck consistently challenges software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently affiliated with Three Rivers Institute and Agitar Software, he is the author of many Addison-Wesley titles.

Clean code that works,in Ron Jeffries' pithy phrase, is the goal of Test-Driven Development (TDD). Clean code that works is a worthwhile goal for a whole bunch of reasons. It is a predictable way to develop. You know when you are finished, without having to worry about a long bug trail. It gives you a chance to learn all of the lessons that the code has to teach you. If you only slap together the first thing you think of, then you never have time to think of a second, better thing. It improves the lives of the users of your software. It lets your teammates count on you, and you on them. It feels good to write it. But how do we get to clean code that works? Many forces drive us away from clean code, and even from code that works. Without taking too much counsel of our fears, here's what we do: we drive development with automated tests, a style of development called Test-Driven Development (TDD). In Test-Driven Development, we Write new code only if an automated test has failed Eliminate duplication These are two simple rules, but they generate complex individual and group behavior with technical implications such as the following. We must design organically, with running code providing feedback between decisions. We must write our own tests, because we can't wait 20 times per day for someone else to write a test. Our development environment must provide rapid response to small changes. Our designs must consist of many highly cohesive, loosely coupled components, just to make testing easy. The two rules imply an order to the tasks of programming. Red--Write a little test that doesn't work, and perhaps doesn't even compile at first. Green--Make the test work quickly, committing whatever sins necessary in the process. Refactor--Eliminate all of the duplication created in merely getting the test to work. Red/green/refactor--the TDD mantra. Assuming for the moment that such a programming style is possible, it further might be possible to dramatically reduce the defect density of code and make the subject of work crystal clear to all involved. If so, then writing only that code which is demanded by failing tests also has social implications. If the defect density can be reduced enough, then quality assurance (QA) can shift from reactive work to proactive work. If the number of nasty surprises can be reduced enough, then project managers can estimate accurately enough to involve real customers in daily development. If the topics of technical conversations can be made clear enough, then software engineers can work in minute-by-minute collaboration instead of daily or weekly collaboration. Again, if the defect density can be reduced enough, then we can have shippable software with new functionality every day, leading to new business relationships with customers. So the concept is simple, but what's my motivation? Why would a software engineer take on the additional work of writing automated tests? Why would a software engineer work in tiny little steps when his or her mind is capable of great soaring swoops of design? Courage. Courage Test-driven development is a way of managing fear during programming. I don't mean fear in a bad way--pow widdle prwogwammew needs a pacifiew-but fear in the legitimate, this-is-a-hard-problem-and-I-can't-see-the-end-from-the-beginning sense. If pain is nature's way of saying "Stop!" then fear is nature's way of saying "Be careful." Being careful is good, but fear has a host of other effects. Fear makes you tentative. Fear makes you want to communicate less. Fear makes you shy away from feedback. Fear makes you grumpy. None of these effects are helpful when programming, especially when programming something hard. So the question becomes how we face a difficult s