敏捷编程的概念出来已经很久了，期间涌现出了很多名词，什么XP啊，Scrum啊，被很多人所推崇。

我想说的是TDD这个东西，也是被很多人认为是保证软件质量的法宝，一旦选择了TDD方式，就自动的获得了设计代码的能力，这其实只是一种假设，不是一种必然。我觉得这些都是错的，不要认为TDD了，就能解决现在的问题。

首先，TDD意味着还未开发就要写大量的测试用例，这本来就是和敏捷开发的初衷是违背的，因为写大量的测试代码，本身就不是敏捷的事情。

Ruby on Rails的作者，在TTD大行其道的时候，冒死说出了TDD已死的，TTD的缺点得到了程序员们重新思考和讨论。那么TDD到底有哪些事情让我这么不爽呢？

首先，维护测试代码的成本很高，目前我所在的团队部分开发正在TDD，这个教条主义式的编程方式，让开发花了大量的时间写测试用例，不要忘了，测试代码也是代码，所有的代码维护成本都是差不多的。一旦业务变更，意味着测试代码需要修改。

其次，TDD的开发方式，我一直认为是反直觉的。试想，你要实现一段程序逻辑，你还不知道会出哪些问题的情况下，先把可能的结果都枚举了一遍，但很多场景下，你只能考虑到有限的一些结果，对于其它的一些问题，更可能是在开发过程中才意识到的。

TDD中的Mock也是一个难题，确定Mock点就会伤掉一部分脑筋，大量使用Mock只是将功能点一个个的分离出来测试，而无法进行集成功能测试。TDD开发人员，在项目工期紧，压力大的环境下，最终沦为为TDD而TDD，写完交差，没有后期维护。

我比较厌恶编程届这种跟风的潮流，总觉得新出来的名词，不学几个就是土的掉渣，落伍的人。比较反感强推某种方法论，而不考虑实际情况。

TDD不是银弹。尤其是在需要敏捷开发的互联网行业，版本的迭代速度非常快，而TDD的这种做法是非常不适合的。我觉得TDD最适合在常规的产品软件中使用，因为版本迭代平稳，周期可控。

不能一棍子打死TDD，TDD确实有它的不少优点，但是衡量是否值得TDD的标准就是投入成本和产出效益之间是否平衡，而不能不顾实际的盲目推崇。软件测试不是只有TDD，找到最合适团队的，才是最好的。

本文转自cnn23711151CTO博客，原文链接：http://blog.51cto.com/cnn237111/1968160 ，如需转载请自行联系原作者