TDD的不足之处

 

    TDD有很多优点，但也有可改进之处，主要在三方面：自动化程度低、对资源利用不充分、干扰编程思维。

    1.自动化程度低

    TDD要求先编写测试代码再编写产品代码，这个编码顺序决定了难以利用工具来生成测试代码。当然，工具也不可能根据测试代码来生成产品代码。如果首先编写产品代码，工具则可以自动生成大部分测试代码，人工一般只需要设定用例的输入输出就可以了。测试代码的编写工作量是很大的。

    TDD要求先编写测试代码的理由主要有两点：一、这是设计行为，可以明确代码需求和设计；二、强制测试，避免先编写产品代码后，忽略测试。

       编写测试代码确实是一种很好的设计行为，但是如果进一步分析，“设计”主要体现在设定用例的输入输出上。假如我们不编写测试代码，而是用表格列出每个用例的输入输出，设计效果与编写测试代码差别不大。

       在编写一个类的测试代码前，难道不需要在心里想清楚类名是什么，父类是什么？在编写一个函数的测试代码前，难道不需要想清楚函数原形，如函数名，返回类型、参数个数、参数类型、参数名？如果这些不确定，如何编写测试代码？在心里想和写出来有本质区别吗？

       如果先编写产品代码的框架，包括类定义和函数原形，则可以用工具生成大部分测试代码。在编写函数的具体实现前，再定义用例，然后再编写代码，其结果和纯粹的TDD有什么区别呢？但效率则可以大幅提升。

      TDD一般使用开源框架，工具缺少自动化功能，遇到问题时很容易卡住，耽误大量时间。例如可测试性，虽然先编写测试代码有利于提高产品代码可测性，但仍然有很多可测性问题无法消除，举个简单的例子：函数中使用了局部静态变量，这种变量，在测试时一般要与全局变量同等对待，每个用例也要设定不同初值，但用例中却不能访问，如何解决？难道为了提高可测性，把局部静态变量都改为全局变量？

      2. 对资源利用不充分

       单元测试的输出可以完整描述程序的行为。程序行为就是在什么输入下，会执行哪些代码，会产生什么输出。写代码时如果能随时察看程序行为，就比较容易想明白思路对不对，接下来应该怎么写，容易找出错误原因，不但效率高得多，也没那么累。

       只要做了单元测试，反映程序行为的数据就一定会存在，这些数据是一种宝贵的资源，工具可以自动捕获，从而让程序行为可视，TDD忽略了这一点。一般的开源框架，只对输出数据进行了判断，只显示测试是否通过，不能显示所有的输入与输出数据，也不能显示用例所执行的代码。

很多时候，实现一个用例对应的功能点是很复杂的，代码可能有几十行，只有等到该功能点写完，程序员才知道测试是否通过。在编写一个功能点的过程中，程序员可能希望每写几行代码，就看看程序做了什么，以便检查和调整思路，找出和修改错误，这是TDD做不到的。

     3.干扰编程思维

      程序员是坚强的，而灵感、创意、思路则是脆弱、易失的。编程工作需要连贯的专注。TDD过程中，编写测试代码大概占用一半时间，而且与编写产品代码交替进行，难免影响编程思维的连贯性。当遇到难题，测试工作卡住时，对开发思维的干扰就更大了。这大概也是很多程序员不愿意编写测试的原因吧。