《最佳实践：测试驱动开发全功略》.doc

最佳实践：测试驱动开发全功略{关键字} 测试驱动开发/Test Driven Development/TDD　测试用例/TestCase/TC　设计/Design　重构/Refactoring {TDD的目标} Clean Code That Works 这句话的含义是，事实上我们只做两件事情：让代码奏效（Work）和让代码洁净（Clean），前者是把事情做对，后者是把事情做好。想想看，其实我们平时所做的所有工作，除去无用的工作和错误的工作以外，真正正确的工作，并且是真正有意义的工作，其实也就只有两大类：增加功能和提升设计，而TDD 正是在这个原则上产生的。如果您的工作并非我们想象的这样，（这意味着您还存在第三类正确有意义的工作，或者您所要做的根本和我们在说的是两回事），那么这告诉我们您并不需要TDD，或者不适用TDD。而如果我们偶然猜对（这对于我来说是偶然，而对于Kent Beck和Martin Fowler这样的大师来说则是辛勤工作的成果），那么恭喜您，TDD有可能成为您显著提升工作效率的一件法宝。请不要将信将疑，若即若离，因为任何一项新的技术——只要是从根本上改变人的行为方式的技术——就必然使得相信它的人越来越相信，不信的人越来越不信。这就好比学游泳，唯一能学会游泳的途径就是亲自下去游，除此之外别无他法。这也好比成功学，即使把卡耐基或希尔博士的书倒背如流也不能拥有积极的心态，可当你以积极的心态去成就了一番事业之后，你就再也离不开它了。相信我，TDD也是这样！想试用TDD的人们，请遵循下面的步骤： 编写TestCase – 实现TestCase – 重构（确定范围和目标） （增加功能） （提升设计） [友情提示：敏捷建模中的一个相当重要的实践被称为：Prove it With Code，这种想法和TDD不谋而合。] {TDD的优点} 『充满吸引力的优点』 完工时完工。表明我可以很清楚的看到自己的这段工作已经结束了，而传统的方式很难知道什么时候编码工作结束了。 全面正确的认识代码和利用代码，而传统的方式没有这个机会。 为利用你成果的人提供Sample，无论它是要利用你的源代码，还是直接重用你提供的组件。 开发小组间降低了交流成本，提高了相互信赖程度。 避免了过渡设计。 系统可以与详尽的测试集一起发布，从而对程序的将来版本的修改和扩展提供方便。 　　TDD给了我们自信，让我们今天的问题今天解决，明天的问题明天解决，今天不能解决明天的问题，因为明天的问题还没有出现(没有TestCase)，除非有TestCase否则我决不写任何代码；明天也不必担心今天的问题，只要我亮了绿灯。 『不显而易见的优点』 逃避了设计角色。对于一个敏捷的开发小组，每个人都在做设计。 大部分时间代码处在高质量状态，100％的时间里成果是可见的。 由于可以保证编写测试和编写代码的是相同的程序员，降低了理解代码所花费的成本。 为减少文档和代码之间存在的细微的差别和由这种差别所引入的Bug作出杰出贡献。 在预先设计和紧急设计之间建立一种平衡点，为你区分哪些设计该事先做、哪些设计该迭代时做提供了一个可靠的判断依据。 　『有争议的优点』 事实上提高了开发效率。每一个正在使用TDD并相信TDD的人都会相信这一点，但观望者则不同，不相信TDD的人甚至坚决反对这一点，很正常，世界总是这样。 发现比传统测试方式更多的Bug。 使IDE的调试功能失去意义，或者应该说，避免了令人头痛的调试和节约了调试的时间。 总是处在要么编程要么重构的状态下，不会使人抓狂。（两顶帽子） 单元测试非常有趣。 {TDD的步骤}　编写TestCase – 实现TestCase – 重构　（不可运行） （可运行） （重构） 步骤 制品　（1）快速新增一个测试用例 新的TestCase　（2）编译所有代码，刚刚写的那个测试很可能编译不通过 原始的TODO List　（3）做尽可能少的改动，让编译通过 Interface　（4）运行所有的测试，发现必威体育精装版的测试不能编译通过 －(Red Bar)　（5）做尽可能少的改动，让测试通过 Implementation　（6）运行所有的测试，保证每个都能通过 －(Green Bar)　（7）重构代码，以消除重复设计 Clean Code That Works {FAQ} [什么时候重构？]　　如果您在软件公司工作，就意味着您成天都会和想通过重构改善代码质量的想法打交道，不仅您如此，您的大部分同事也都如此。可是，究竟什么时候该重构，什么情况下应该重构呢？我相信您和您的同事可能有很多不同的看法，最常见的答案是“该重构时重构”，“写不下去的时候重构”，和“下一次迭代开始之前重构”，或者干脆就是“最近没