不要宗教化TDD(测试驱动开发)

敏捷编程的概念出来已经好久了，期间涌现出了不少名词，什么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，找到最合适团队的，才是最好的。