【转】TDD是一道坎

如果一个系统都是大的类和函数，一个文件上万行，到处是依赖和关联，这样的系统是很难甚至无法进行单元测试。我在给大家做测试培训的时候，让大家列出单元测试的好处，有人提出很重要的一点：测试是站在代码的使用角度看问题或思考

单元测试，不仅仅是测试，更多的是测试在使用我们的类和函数，逐个验证这些函数是否按照我们期望工作，也就是变相的帮助大家对函数功能进行解耦。再说通俗一点，通过写单元测试，就知道我们代码写的好坏。其中有两层含义：一、是代码的功能是否正确 二、设计是否良好，功能是否解耦。这也是为什么大家一直在说：测试可以驱动设计，测试督促开发人员从测试（使用者）和质量的角度去思考自己写的代码。

有人在产品失败或者代码腐化的时候，最喜欢义正言辞的说一句：“如果给我一个机会再来一次的话，我一定会设计一个很好的系统”。当然，这也只能是马后炮。我相信，就算再给他一次机会，往往还是同样的结果收场。这是为什么呢？为什么我们不能一次性的把软件系统设计的非常完美呢？

原因是我们的系统永远在变化。在做第一个版本的时候，没有人会知道第二个版本（第三个版本、第四个版本）的会有什么样的需求。那我们如何才能一次性的把代码写好，在后期的新需求或变更需求的时候可以最小的成本来应对呢？

对这个问题，我们的答案是：TDD。但也千万不要神话TDD，这只是一个非常有效的开发实践或者是工作方法或者是行之有效的解决方案，并且已经在软件业界得到充分的认可。如果你做不好TDD或者没有能力去做TDD，不要去指责TDD实践本身，不要说TDD没用，应该勇敢的站起来说：我现在还没有能力做好TDD。

TDD对开发人员要求很高（Too Difficult To Do)。因为TDD不再是单纯的堆砌代码，TDD是：

1. Test First，也就是在写代码之前先必须完全理解业务，因为如果不清楚自己要做什么（业务没有理解清楚）就根本无法写测试
2. Use it before implement it, 这就更难了，也是我们这里最需要的。实现一个函数之前，先使用它。这就督促我们对代码进行解耦，如果程序之前依赖太多，那么函数就很难被独立使用，换句话说就是写单元测试非常困难。所以，我们也称TDD为设计驱动开发。
3. 提前对代码的功能进行验证，每一块代码都得到事先的验证，并且是自动化可回归。
4. 尽量一次性的把代码写好。TDD要求大家从测试和质量的角度思考问题，尽可能的考虑所有的边界条件和异常分支
5. 支持重构，为代码和架构的演变提供了一张牢固的安全网

那么，再具体一点，TDD对开发人员到底有什么样的要求呢？是要求开发人员个个聪明智商过人吗？不，TDD要求如下：

1. 开发人员精通所用的语言和工具，有能力写出高质量的代码
2. 开发人员有很强的责任感。认为一次性的把代码写好是自己分内的事情，主动追求优雅和高质量的代码
3. 公司和团队有正确的意识和导向，理解、支持和鼓励开发人员一次性把工作做好。其实，这个坎最难。TDD存在着交付与质量，短期利益与长期利益
4. 的平衡。在一个急于求成的团队中引入TDD将会非常困难。

TDD是一道坎，是我们ThoughtWorks和软件业界认可正确并可以彻底解决产品质量的一项实践。作为一个TW顾问，我们的职责是指导大家做更好的软件，提高产品质量，消除软件过程中的浪费。我们会坚持带领我们的客户去做正确的事情，提高客户的项目管理、需求分析和产品交付等方面的能力。