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

前端之家收集整理的这篇文章主要介绍了不要宗教化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,找到最合适团队的,才是最好的。

原文链接:https://www.f2er.com/javaschema/282605.html

猜你在找的设计模式相关文章