重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
偶尔翻到自己五年前写的关于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