TDD,Dont DDT

2008-03-04 23:39:12

一直有个疑问，对于遗留系统，我们该如何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信息提示完善你的功能代码，这个时候开发已经相当轻松了。