早就听说TDD的大名，一直没有机会使用。这次Mrpc框架开发的时候正好用用看。在此之前，先学习一下TDD。
本篇大部分结论来自http://www.jb51.cc/article/p-fajbbeng-ch.html
TDD的步骤
- 加入一个新的测试
- 运行下新加的测试，看到它失败（因为你还没写功能代码）
- 对开发代码做很小的修改，目的就是让新加的测试通过 （注意这里的目的）
- 运行所有的测试（test case），然后看到所有测试都通过了 （看到测试都变成绿色，一般都会小开心一下）
- 移掉重复的代码，对代码进行重构 （既包括功能代码，也包括测试代码。特别注意红色的字串 一般会有重复，还有一些代码可以抽出来变成公用方法，测试代码中同样的初始化和还原测试环境的代码，可以放到intilize和cleanup中去）
而外还有一些步骤也是可以加入的，比方
- 在写测试代码前，先从需求出发，准备一个Test list (需要测到的功能的列表)。忘掉你该怎么实现，那是后面的事情
- 每测完一个就用横线划掉
- 如果发现有漏掉的test 就加到这个列表中（列表测完你的功能也就完成了）
TDD能带来的好处
你会更加站在用户的角度去看你将要完成的产品，你要尽可能想到用户所有进行的操作。而不是从程序员的角度想用户应该会如何去使用我们的产品。
它使我们对自己代码有了信心，因为我们事先设计好的所有测试用例都Pass了。
哈！我们的一整套完备的测试用例在这里替我们把关（把的什么关？），我们就可以十分安全的使用极限编程的另一个最重要的工具——重构。重构改变的是代码的内部结构，而不会改变外部接口功能。知道在做重构时测试用例是把的什么关了吧！很明显，测试用例是保证我们在进行重构时，不会影响到代码的外部接口功能。所以我刚刚说，我们进行的重构是十分安全的。
基于第5点，我们找到了重构的信心，必要时候你还可以痛痛快快的并且满怀信心的对代码做一场大的变革。这样我们的代码变得干净了，扩展性、可以维护性以及易理解性纷至沓来。
首先站在客户方代码的立场，可以获得更好的api。
其次可以改善软件质量，支持重构。
其三，大幅减少debug时间。
前期投入大，后期能大幅缩短开销，将问题发现在最源头提供明确的目标:
你很清楚,一旦结束(测试通过),你的工作就完成了(假设你的测试写的很好). 测试代码会为代码建立一个自然的边界,使你把重点集中在当前任务上. 一旦测试通过,就有确切的证据证明你的代码能工作. 相对于人工的测试用户界面或者比较日志文件中的结果,在一个xUnit框架中运行自动化测试,速度要快几个数量级. 大多数xUnit测试的运行只需几微秒,而且大多数采用TDD的人都会一天运行数次测试. 在许多开发小组中,将代码上传配置库前,必须成功地通过测试.提供文档
你是不是经常遇到看不懂的代码? 这些代码可能没有任何文档说明,而且开发代码的人可能早就走了(或者去度假了). 当然看到这种代码的时间往往也很不合时宜,可能是凌晨3点,也可能有位副总在你旁边大声催促着赶快解决问题,这样要想花些时间来愿作者的意图就更困难了. 我们见过一些好的单元测试文档,它们会指出系统要做什么. 测试就像原开发人员留下的记号,可以展示他们的类具体是怎么工作的.改善设计
编写测试能改善设计. 测试有助于你从界面的角度思考,测试框架也是代码的客户. 测试能让你考虑得更简单. 如果你确实遵循了”尽量简单而且行之有效”的原则,就不会写出篇幅达几页的复杂算法. 要测试的代码通常依赖性更低,而且相互之间没有紧密的联系,因为这样测试起来更容易. 当然,还有一个额外的作用,修改起来也会更容易!鼓励重构
利用一套健壮的测试集,你能根据需要进行重构. 你是不是经常遇到一些不知是否该修改的代码? 种种的顾虑让你行动迟缓,过于保守,因为你不能保证所做的修改会不会破坏系统. 如果有一套好的单元测试集,就能放心的进行重构,同时能保证你的代码依然简洁.提高速度
编写这么多测试会不会使开发速度减慢呢? 人们经常会以速度(或开发开销)作为反对进行TDD和使用xUnit框架的理由. 所有的新的工具都会有学习曲线,但是一旦开发人员适应了他们选择的框架(通常只需要很短的时间),开发速度实际上会加快. 一个完备的单元测试集提供了一种方法对系统完成回归测试,这说明,增加一个新特性之后,你不必因为怀疑它会不会破坏原系统而寝食难安.提供反馈
单元测试还有一个经常被忽略的优点,即开发的节奏. 尽管看上去好像无关紧要,但通过测试之后你会有一种完成任务的成就感! 你不会成天地修改代码而没有任何反馈,这种测试-代码-测试的方法会鼓励你动作幅度小一些 通常修改一次代码的时间仅仅几分钟而已. 这样你不会一下子看到冒出一大堆新的特性,而只是让代码每次前进一小步.
TDD的缺点
TDD有这么多好处，但它也不是免费的午餐，它需要我们有设计完备的测试用例的能力（这项能力是长期理论与实践的结合体），否则你将会吃了亏编写了一大堆测试用例，却没测到点子上。可怕的是，你还对你“测试通过”的糟糕的代码满怀信心。
质量是反复思考的结果，仅靠解决Bug无法获得
原文地址：https://www.jb51.cc/javaschema/283355.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
