「勿忘初心」TDD,Dont DDT

前端之家收集整理的这篇文章主要介绍了「勿忘初心」TDD,Dont DDT前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

偶尔翻到自己五年前写的关于TDD的文章,又看一遍, 感觉当时的自己是走在正确的路上。但是这么多年过去了,BDD也在流行,自己却没有一直沿着这条路走下去,为什么? 老文重拾,感慨良多。

这个过程是我当时在用Ruby改造一个PHP的遗留系统,具体细节已遗忘。


正文

一直有个疑问,对于遗留系统,我们该如何TDD ?

我个人比较认同TDD是一种设计方法,不能代替真正意义上的测试。是帮助我们设计自己代码的一种方法。对于遗留系统,面对一堆需求文档,面对一陀陀已经难 以继续维护的陈旧代码,你的心是否哇凉哇凉的 ?做为一个使用Rails的开发人员,难道你要把这些代码翻译为Ruby代码吗 ?
答案当然是不!
很多时候,我们虽然很清楚要TDD,但是很多时候我们是在DDT。基本上是根据遗留系统的代码功能代码写的差不多了,才想起来写测试。写完之后, 用流行的rcov测试一下测试代码覆盖率,不足的地方再加上测试 ? 回头想想,我们引入TDD的初衷是这样的吗 ? 大家都心知肚明,并不是这样的!
重新思考TDD之后,我决定在现做的这个ticket里完全采用了TDD的方式去开发,今天一天下来,感触颇深:
1。 昨天拿到PHP源码,一看代码,了不得啊,和我功能相关的源码文件之有三个,但代码却有三千多行。我该怎么办 ?我肯定不可能把那三千多行都看完吧。我该如何TDD ?
T代表Test,测试驱动开发,很显然,是先有测试,要不谈何驱动开发。 但是没有功能代码,你测试什么呀? 既然TDD是一种设计方法,那么这个测试,代表的应该是你大脑中对这个功能的自我认知。 如果对需求了解不清楚,你是没有办法对这个功能产生自我的认知的。硬着头皮整理了一下需求文档,在脑中形成一个大概的轮廓之后,就可以动手写测试了。此功 能是要生成一个报表,就是一个create -> show 的过程。一般人想到的先是页面,我是一般人,所以我也是从页面开始的,根据已经明确的需求写下自己对这个页面的幻想:

因为51cto的代码格式问题,

更详细的点击:原文地址: http://tao.logdown.com/posts/158033-do-not-forget-the-chuxin-tdddont-ddt

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

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