摘要：在软件行业中，神仙打架的名场面，那就不得不提的是2014年的那场——测试驱动开发（TDD）之争。
在历史上有不少精彩绝伦的神仙打架，好比数学界的牛顿和莱布尼茨关于微积分的旷世之争；好比量子物理中的爱因斯坦和波尔的紫禁之巅；好比足球里的梅西和C罗的旗鼓至关难分高下；又好比滴滴和快滴之间触目惊心的烧钱大战……而在软件行业中，也一样有神仙打架的名场面，那就不得不提的是2014年的那场——测试驱动开发（TDD）之争。程序员
比赛的红方是David Heinemeier Hansson，蓝方是Kent Beck。David Heinemeier Hansson 因为名字较长简写成DHH，Ruby on Rails 正是出自于DHH之手。而这场打架还加入了“裁判”员——Martin Fowler，在比赛中Martin Fowler记录了红蓝双方的每一次组合拳、上勾拳、侧踹、抱摔……总结以下：编程
红方DHH观点：
- 许多推进TDD的开发人员会让你以为：若是你不使用TDD的话，你的代码就是肮脏的。
- 由单元测试开始驱动你的设计并非一个好的主意。
- TDD的概念“测试必须够快”是目光短浅的。
- 对TDD的依赖会致使完全忘记系统测试。
- 关注而且只关注单元模块并不能有助于建立一套完美的系统。
- 100%的覆盖率是愚蠢的。
- 程序员但愿软件是一门科学，但是它并非。它更像是创造性的写做活动。
- 优秀的软件并不像工程学那样，它更像写做。清楚简洁的写做要优于复杂晦涩的写做。
- 清晰是有好处的，好到应该将清晰性做为第一目标，而非测试覆盖度或者测试速度。
- 成为一名优秀的开发人员就像成为一名优秀的做家同样困难。
- 就像写做同样，成为优秀的程序员的办法就是以清晰为目标从而大量编写软件、大量阅读软件。
蓝方Kent Beck观点：
DHH已将TDD委托给历史垃圾堆。我很难过，不是由于我就把它从历史的垃圾堆中拯救出来，而是由于如今我须要雇佣新技术来帮助我解决编程过程当中的许多问题：设计模式
- 过分工程化。我倾向于“投入”我“知道”我“将须要”的功能。使一个红色的测试变为绿色（以及将来的测试列表）有助于我实现足够的功能。我须要找到一个新的方法来保持专一。
- API反馈。我须要找到一种新的方法来得到关于个人API决策的快速反馈。
- 逻辑错误。我须要找到一种新的方法来抓住那些我很容易犯的讨厌的测试错误。
- 文档。我须要找到一种新的方式来传达我对api的指望，并记录我在开发过程当中的想法。
- 感到不知所措。我真的会怀念如何使用TDD，即便我没法想象一个实现，我几乎总能想出如何编写测试。我须要找到一个新的方法，以便下一步上山。
- 将接口与实现思想分离。我倾向于用实现推测来污染API设计决策。我须要找到一种新的方法来分离这两个层次的思惟，同时在它们之间提供快速的反馈。
- 协议。我须要找到一个新的方法，精确地与一个编程伙伴关于我正在解决的问题。
- 焦虑。也许我最怀念的是TDD给个人瞬间“一切都好吗？”按钮。
- 我相信我会找到其余方法来解决这些问题。及时。疼痛会减轻的。再见TDD，老朋友。
神仙打架不亏是神仙打架，从那之后业界关于测试驱动开发的观念也分红了两派。一派主要来源自像国内的一些互联网等项目中声音——需求的迭代和更新之快，要求公司或团队能快速交付有价值的产品，而TDD对于不少开发人员来讲无疑是带来了繁重的工做压力和交付压力。甚至有人开玩笑话说：“ Deadline Driven Development 才是第一辈子产力 ”。api
固然也有人力挺TDD，“TDD并无死。很明显，既然它有这么这么多的支持者，它怎么可能会死呢? 这就像在问，设计模式死了吗？或者功能性自动化死了吗？不，它并无死。并且它在未来任什么时候候都不会死亡。它未来可能会变成其余一些新的事物、甚至是一些更好的事物，可是它永远不会死亡。因此让咱们跳过这一部分吧。”函数
关于测试驱动开发说了这么久，那么测试驱动开发究竟是个啥呢？单元测试
测试驱动开发（TDD）是什么
测试驱动开发，英文全称Test-Driven Development，简称TDD，是一种不一样于传统软件开发流程的新型的开发方法。 它要求在编写某个功能的代码以前先编写测试代码，而后只编写使测试经过的功能代码，经过测试来推进整个开发的进行。 这有助于编写简洁可用和高质量的代码，并加速开发过程。学习
Kent Beck：“测试驱动开发不是一种测试技术。它是一种分析技术、设计技术，更是一种组织全部开发活动的技术”。测试
分析技术： 体如今对问题域的分析，当问题尚未被分解成一个个可操做的任务时，分析技术就派上用场，例如需求分析、任务拆分和任务规划等，《实例化需求》这本书能够给予必定的帮助做用。url
设计技术： 测试驱动代码的设计和功能的实现，而后驱动代码的再设计和重构，在持续细微的反馈中改善代码。spa
组织全部开发活动的技术： TDD 很好地组织了测试、开发和重构活动，但又不只限于此，好比实施 TDD 的前置活动包括需求分析、任务拆分和规划活动，这使得 TDD 具备很是好的扩展性。
测试驱动开发（TDD）的目标
Kent Beck 在他的著做《Test-Driven Development》（见参考附录）一书中提到：“代码简洁可用这句言简意赅的话，正是 TDD 所追求的目标”。
对于如何保证“代码简洁可用”可使用分而治之的方法，先达到“可用”目标，再追求“简洁”目标。
可用： 保证代码经过自动化测试。
代码简洁： 在不一样阶段人们对简洁的理解程度也不同，不过遵循的原则差很少，例如 OOD 的 SOLID 原则（详见参考附录），Kent Beck 的 Simple Design 原则（详见参考附录）等。
虽然有不少因素妨碍咱们获得整洁的代码，甚至可用的代码，无需征求太多意见，只须要采用 TDD 的开发方式来驱动出简洁可用的代码。
测试驱动开发（TDD）的规则
在TDD 的过程当中，须要遵循的三项原则：
- 在编写好失败的单元测试以前，不要写任何产品代码。
- 只要有一个单元测试失败了，就不要再写测试代码。没法经过编译也是一种失败。
- 产品代码刚好可以让当前失败的单元测试成功经过便可，不要多写。
测试驱动开发（TDD）的流程
测试驱动开发是一个过程，依赖于不断重复极短的开发周期，这个周期也称为“红灯-绿灯-重构”，如上图。简单的来讲，基于TDD的三项原则，TDD的这种步骤（周期）以下：
- 添加一个小的测试
- 运行测试并查看失败
- 对测试进行微小的改动经过测试
- 运行全部测试并看到其经过
- 经过重构去掉重复部分
须要注意的是，不一样阶段有不一样的目的，他们须要不一样的解决方案，前二个阶段须要很快地完成，以便知道新添加功能的状态。为了达成这个目的，能够经过任何手段，由于仅在这时才这样作，也是为了能快速完成好的设计。
测试驱动开发（TDD）的好处
TDD主要的好处主要包括了，肯定性、重构代码、单元测试即文档。
肯定性。TDD提高了单元测试的覆盖率，在每轮迭代产品都会新增代码，若是有一套覆盖率很高（ 90% 或更高）的单元测试，那么只需执跑一遍测试用例，那么能成功交付的把握就会比较大。反之，若是覆盖率越低，越须要更多的人力去进行手动验证。 在 kent Beck的《测试驱动开发》举的例子中，正因有了TDD才有勇气和老板说咱们能够作！这就是TDD最强大的地方，它让你拥有一套值得信赖的测试，打消你对修改代码的恐惧。
重构代码。Martin Flower在他的《重构》中也指出，完善的单元测试是他进行重构的基石，从TDD的流程能够看到，重构是TDD的一部分，运用TDD的同时也推进了代码的重构。
单元测试即文档。在软件行业里，人员的变更的很频繁的，若是要尽快熟悉某个模块的业务逻辑。看文档？程序员写的文章通常都不太容易看，并且文档常常会和代码不一样步，代码修改了文档没跟着改的事情常常发生。看源码？看完也不必定知道为何。若是这时候有一套很是完整的单元测试，那可能就是全部接手别人代码的程序员的福音。首先，代码不会撒谎，其次，测试用例明确告诉了你这个函数是作什么的，什么输入对应的都有什么预期输出。单元测试就是最好的底层文档，哪一个专业人士不想提供这样一份文档呢？
此外，TDD还可以促成良好的代码设计。因为你先写测试代码，你会尽量的让代码调用起来更加简单方便，这也就促使你去考虑如何更好的设计代码。以免会出现一个函数里实现的功能过多，或者和其余代码过于耦合而没法测试的状况。
固然测试驱动开发除了好处之外，还有神仙打架中红方表明DHH所提出的一些问题。总结来看，关于TDD的争议能够大体从这几个方面来看，软件开发应该由什么来驱动，测试的速度和覆盖程度，以及设计思想层面等几方面。从 辩证统一的角度来看，事物有两个方面， TDD不必定能适用于全部的场景，一样TDD的局限性在某些场景下也不见得是对的，若是想要能更好的适用于自身，不只要拿捏好度的问题还要以敏捷的思想来应对问题，好比不该该盲目的制定100%或0%的测试覆盖率，也不该该固化开发步骤而不顾实际状况。
因此，在最后的神仙打架中，Kent Beck也表达了David的论述可能会让TDD浴火重生、凤凰涅槃的观点，但愿能够找到更加好的方法。但不管如何， 在咱们实际工做中，不该该由于某些 观点成为咱们接受或者拒绝它的理由。正所谓大道甚夷，而民好径，做为敏捷开发中的一项优秀实践来看，TDD只有在真正使用事后才能评价是否已死的问题。那么你在践行敏捷开发的时候，是否使用过TDD这种实践呢，又或是践行过其余一些敏捷开发的实践呢，有没有评测过你所在的项目中的敏捷开发的成熟度是如何的呢？
没有那就对了！
华为云的DevCloud专业服务正是为此而生！
针对不一样的岗位提供了评估的能力，让开发者能够对号入座，并基于你所在的岗位、技术获得客观、全面、系统的测评以及名师般的学习引导。快来访问 专业服务平台，经过我的能力评估，看看本身是什么水平吧！
本文分享自华为云社区《快来看神仙打架啊》，原文做者：敏捷的小智。