测试驱动开发（影印版） - (2008 年度畅销榜NO.555 )

本书从头到尾跟踪介绍了两个TDD项目，描述了程序员容易上手又能大大提高工作质量的技术。在涉及TDD最有特色的模式和重构后面都附有例子。通过将侧重点放在灵活的方法和快速开发的策略上，肯定能激发读者接受这些未被充分利用但功能强大的技巧。本书是Kent BecK先生的最新力作，在亚马逊网站上持续热卖，是Addison-Wesley出版公司著名的大师签名系列图书之一。

Preface\r\nAcknowledgments\r\nIntroduction\r\nPART I:The Money Example\r\nPART II:The xUnit Example\r\nPART III:Patterns for Test-Driven Development\r\nAfterword\r\nIndex

Kent Beck是软件开发方法学的泰吉、XP的创始人，长期致力于软件工程的理论研究和实践，并具有讲授XP的丰富经验。作为软件业内最富创造性和最有口碑的领导人之一，Kent Beck极力推崇模式、极限编程和测试驱动开发。他现在加盟于Three Rivers 研究所，是多部畅销书如《Smalltalk Best Practice Pattrns》、《解析极限编程拥抱变化》和《规划极限编程》的作者，并且是超级畅销书《重构——改善既有代码的设计》的特约撰稿人。

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. 1. Red--Write a little test that doesn't work, and perhaps doesn't even compile at first. 2. Green--Make the test work quickly, committing whatever sins necessary in the process. 3. 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 situation and, Instead of being tentative, begin learning concretely as