浅谈对TDD的看法

程序猿对TDD这个词一定不陌生。近几年比較火。英文全称Test-Driven Development，測试驱动开发。

它要求在编写某个功能的代码之前先编写測试代码，然后仅仅编写使測试通过的功能代码，通过測试来推动整个开发的进行。

以下这段是粘的（来自百度百科）。列举了TDD相比传统开发模式的一些优势：

1) TDD依据客户需求编写測试用例，对功能的过程和接口都进行了设计，并且这样的从使用者角度对代码进行的设计通常更符合后期开发的需求。

由于关注用户反馈，能够及时响应需求变更。同一时候由于从使用者角度出发的简单设计，也能够更快地适应变化。

2) 出于易測试和測试独立性的要求，将促使我们实现松耦合的设计，并很多其它地依赖于接口而非详细的类，提高系统的可扩展性和抗变性。并且TDD明显地缩短了设计决策的反馈循环，使我们几秒或几分钟之内就能获得反馈。

3) 将測试工作提到编码之前。并频繁地执行全部測试，能够尽量地避免和尽早地发现错误。极大地减少了兴许測试及修复的成本。提高了代码的质量。在測试的保护下，不断重构代码。以消除反复设计。优化设计结构，提高了代码的重用性。从而提高了软件产品的质量。

4) TDD提供了持续的回归測试，使我们拥有重构的勇气，由于代码的修改导致系统其它部分产生不论什么异常。測试都会立马通知我们。完整的測试会帮助我们持续地跟踪整个系统的状态。因此我们就不须要操心会产生什么不可预知的副作用了。

5) TDD所产生的单元測试代码就是最完美的开发人员文档，它们展示了全部的API该怎样使用以及是怎样运作的。并且它们与工作代码保持同步，永远是最新的。

6) TDD能够减轻压力、减少忧虑、提高我们对代码的信心、使我们拥有重构的勇气，这些都是快乐工作的重要前提。

7)高速的提高了开发效率

当我看到这些优势后，我为之中的一个震，这个东西好，但细致思考后，认为非常多地方并非那么easy的。也不像TDD宣称得那么乐观。

以下针对上述每一条优势，谈谈我的看法。 

针对第一条：

“TDD依据客户需求编写測试用例”，“从使用者角度对代码进行设计”。但经过无数实践证明。软件开发的最大困难在于用户需求的不确定性。依据用户需求编写測试用例，除非针对一些非常easy或者非常明白的需求。否则你的測试用例根本不能真正反映用户的需求。TDD从一定程度上提前做了一个如果。那就是“需求能够在实现之前明白下来”，这是不现实的。

在实际的软件开发中，用户需求和外部环境的不稳定性会导致软件需求难以把握。仅仅有让用户看到了执行的软件，用户才干驱使软件朝着他想要的方向前进，通常需求和设计都会不断调整。

针对第二条：

我不否认測试能够驱使我们写出更高质量的代码，但这是測试的作用。并非TDD的作用，“在没有測试用例失败之前，不要写不论什么一行代码”这样的极端的方式，会导致我们的设计不是迎合用户需求，而是迎合測试用例，而如前面所说，測试用例非常难在一開始就符合用户需求。

我们全然能够在完毕系统功能的同一时候。完毕单元測试，然后通过重构的方式来改善既有代码的质量。

针对第三条：

不可否认，“频繁地执行所有測试，能够尽量地避免和尽早地发现错误，极大地减少了兴许測试及修复的成本，提高了代码的质量。

”但假设把这些放在代码之前。那么我们怎样保证自己的測试用例写得恰当，一旦需求变更，或者对需求理解有误，那么改动測试用例。意味着我们的编码所有废弃了，不要小看这个成本。非常可能会出现这样的情况：我们花成倍的时间去维护我们的測试用例，却不能如期交付我们的软件。

第二句，“在測试的保护下。不断重构代码。以消除反复设计，优化设计结构，提高了代码的重用性，从而提高了软件产品的质量。”这是单元測试的功能。并非TDD的功劳。

第四条，第五条。第六条提到的也是一样。并非TDD的功劳，是自己主动化測试的功劳。自己主动化測试并非什么新东西。从Junit出现的那天，自己主动化測试就已经非常成熟了。TDD包括自己主动化測试，假设TDD的全部优势都来源于自己主动化測试。那么TDD全然是一个大忽悠。

针对第五条。多说一句，“TDD所产生的单元測试代码就是最完美的开发人员文档”，这样的鬼话，我是不信的。自己主动化測试用例的开发维护成本远高于文档。它对程序猿的个人素养也要求很高。意味着什么？成本很高。

第七条更无从谈起了。“高速的提高了开发效率”？ 前面说了那么多。这句就不用再评论了。

总结：

看到TDD。我就想到了瀑布模型。

TDD强调“先理解清楚需求，把它转化为測试用例，然后再来实现和重构“，细一琢磨。这不就是瀑布模型嘛？强调需求先于实现，瀑布模型用文档表达需求，而TDD仅仅只是是把需求文档换成了測试用例而已。

所以我觉得，TDD不是什么新东西，仅仅只是在瀑布模型的基础上换了身衣服。带了个自己主动測试的帽子而已。它将不可避免地面临和瀑布模型同样的问题：“忽略了软件需求的产生是一个在实际执行中不断调整探索完好的过程。

”

个人愚见，勿喷。