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

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

正文

一直有个疑问，对于遗留系统，我们该如何 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. 运行测试，报错，没有 company name: , 好办啊，在 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 覆盖率的时候绝对是百分百覆盖的。