TDD,Dont DDT

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

我个人比较认同TDD 是一种设计方法，不能代替真正意义上的测试。是帮助我们设计自己代码的一种方法。对于遗留系统，面对一堆需求文档，面对一陀陀已经难 以继续维护的陈旧代码，你的心是否哇凉哇凉的 ？做为一个使用Rails 的开发人员，难道你要把这些代码翻译为Ruby 代码吗 ？

答案当然是不！

很多时候，我们虽然很清楚要TDD ，但是很多时候我们是在DDT 。基本上是根据遗留系统的代码把功能代码写的差不多了，才想起来写测试。写完之后， 用流行的rcov 测试一下测试代码覆盖率，不足的地方再加上测试 ？ 回头想想，我们引入TDD 的初衷是这样的吗 ？ 大家都心知肚明，并不是这样的！

重新思考TDD 之后，我决定在现做的这个ticket 里完全采用了TDD 的方式去开发，今天一天下来，感触颇深：

1 。 昨天拿到php 源码，一看代码，了不得啊，和我功能相关的源码文件之有三个，但代码却有三千多行。我该怎么办 ？我肯定不可能把那三千多行都看完吧。我该如何TDD ？

T 代表Test ，测试驱动开发，很显然，是先有测试，要不谈何驱动开发。 但是没有功能代码，你测试什么呀？ 既然TDD 是一种设计方法，那么这个测试，代表的应该是你大脑中对这个功能的自我认知。 如果对需求了解不清楚，你是没有办法对这个功能产生自我的认知的。硬着头皮整理了一下需求文档，在脑中形成一个大概的轮廓之后，就可以动手写测试了。此功 能是要生成一个报表，就是一个create -> show 的过程。一般人想到的先是页面，我是一般人，所以我也是从页面开始的，根据已经明确的需求写下自己对这个页面的幻想：

/spec/views/reports/new.html.erb_spec.rb 中：

require File.dirname(__FILE__) + '/../../spec_helper'

describe "reports/new.html.erb" do

......

it "should render new.html.erb" do
render "/reports/new.html.erb"

response.should have_tag("form[action=/reports/new]") do

#应该有一个label来表明这个field是company name

with_tag('label',"company name:")
with_tag('select#data_company_id[name=?]',"data[company_id]")

＃应该有个下拉列表来让用户选择存在的company name
with_tag('label',"Report Filter by Year:")
＃应该有个时间列表来让用户选择生成报表数据的时间段。 with_tag('select#report_filter_by_year[name=?]',"report_filter[by_year]")
end
end
.... ..

end

好了，写到这，我脑中只剩下了一点不清楚的需求。也就是说，我如果能把这个测试写完，脑中对这部分的需求应该就明朗了。继续看文档，看php 代码，只看一 些sql 语句。一个疑问就是这个页面用不用加一个排序的下拉列表 ？ 这个疑问得问和我们合作的老外Andy ，正好他还未到睡觉时间，就问他：

new page whether should need select down list to sort by some column ? 他回答 ： sounds like good .

very good,我可以把上面这句英语翻译成rspec 代码：

with_tag('label',"Sort by:")
with_tag('select#sort_by_sorted_on[name=?]',"sort_by[sorted_on]")

这样我的这个测试就全部写完了：如下

require File.dirname(__FILE__) + '/../../spec_helper'

describe "reports/new.html.erb" do

......

it "should render new.html.erb" do
render "/reports/new.html.erb"

response.should have_tag("form[action=/reports/new]") do
with_tag('label',"company name:")
with_tag('select#data_company_id[name=?]',"data[company_id]")
with_tag('label',"Report Filter by Year:")
with_tag('select#report_filter_by_year[name=?]',"report_filter[by_year]")

with_tag('label',"Sort by:")
with_tag('select#sort_by_sorted_on[name=?]',"sort_by[sorted_on]")

end
end
.... ..

end

打开autotest,运行，报错：没有这个页面。好办啊，建个页面不就得了。建立new.html.erb.

运行测试，报错，没有 <label> company name: </label>,好办啊，在new.html.erb 里加个label 不就得了。

根据错误信息的提示，我很快就把页面的基本元素写好了。

但是下拉列表的选项，是需要从数据库里查询来生成options 的。那么就在model 里写个测试方法了：

＃应该返回一个以年份组成的二维数组
it "should return a array by year" do
year = Entry.get_filter_year
year.should be_an_instance_of(Array)
year[0].should be_an_instance_of(Array)
end

这样，运行autotest ，会报错，Entry 没有定义get_filter_year 方法，好办啊，加上不就得了吗。

。。。 。。。

不断的根据错误提示来写功能代码。

。。。。

测试终于全部通过。

我的功能代码也完成了。

我对页面的那点幻想终于成了现实。

这就是TDD 。

这个TDD 的过程里，我没有开过浏览器。一点不吹牛，信不信由你！

TDD 的好处：

1 。帮助你理清思维，去把遗留系统的需求逐步的挖掘出来，而不用去把客户给的三千行代码看完。

2 。驱动你的开发。整理需求写完测试之后，然后只需要运行autotest 来利用failure 信息提示完善你的功能代码，这个时候开发已经相当轻松了。

3 。 这样写的功能代码用rcov 测试test 覆盖率的时候绝对是百分百覆盖的。