TDD实践小结

所谓TDD，就是测试驱动开发。近期看了一些如何写代码的书，包括《修改代码的艺术》，《代码整洁之道》等，这些书都提到了TDD。

我记得几年以前在书店就开始看到关于极限编程的书，也偶尔听到测试驱动开发的概念。大体的思想就是在实现一个功能时，先写测试用例，

再写代码，然后让代码 通过测试用例。通过不断的迭代，来完善所开发的功能。

我以前也尝试过TDD，虽然也有收益，但现在看来，当时做的还不算TDD。主要原因是我的单元测试的粒度太粗糙，因为不会打桩，很多分支和

逻辑都走不到，而且因为需要真实的环境（比如需要真实的数据库环境），所以测试代码的维护成本较高，并且测试用例运行的时间也较长。

这些都让TDD很难持续下去，我觉得我当时的单元测试用例，更像是集成测试用例。而且这种测试用例往往是一次性的。

最近我对TDD产生兴趣的重要原因是我现在调试程序的成本比以前要高的多了。如果你在真实环境中发现并解决一个bug需要至少2个小时的话，

你肯定希望代码在真实环境测试前bug已经被消除。TDD的价值就在于此。

但TDD不能发现所有的bug，有两类bug，TDD是无能为力：

第一个是与操作系统的接口层，或者其他第三方库的接口层， 如果程序包括界面，还包括界面相关代码，这部分UT测试不到；

第二个是设计者逻辑上的理解错误，当我们期望的结果就是错的时候，UT就无能为力了。

除此之外，UT都可以测到，通过打桩的办法，可以实现分层测试，并且可以把每个UT的运行时间控制在毫秒级别。

我前段时间添加一个新功能，用TDD的方式来做，大概写了700多行测试代码，300多行正式代码。在编码过程中，发现了好几个

bug，但是在真实环境中调试还是遇到了问题，后来分析遇到的问题，就是前面说的这两种情况。其他的bug，都在调试之前解决掉了。

即使这样，我从开始调试到解决问题还是用了一天的时间。如果没有TDD估计效率只会更低。

还有一点，TDD不能完全取代设计，虽然TDD本身是个设计的过程，在做TDD前，要有一个初步的设计方案。

另外，如果要写出好代码，光有TDD不够，要能熟练运用各种设计模式。