「勿忘初心」TDD,Don't DDT

Published on:
Tags: ruby

偶尔翻到自己五年前写的关于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.
运行测试,报错,没有 , 好办啊,在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覆盖率的时候绝对是百分百覆盖的。


补:有人问, 能否推荐一个比较优秀的TDD/BDD案例?

大家可以看看这个,2013 Rails Rumble Gem Teardown。 Rails Rumble每年都会举行48小时的创业大赛,参赛的队伍必须在48小时内写出自己的参赛作品,这篇文章通过分析参赛队伍的Gemfile来统计了一些Gem的使用情况。 其中,我们可以发现有些团队是使用了TDD/BDD的Gem的,比如Rspec,但是具体他们有没有写测试代码就没有具体分析了。

我觉的想找出TDD/BDD比较优秀的案例,可以从参赛队伍的作品里去寻找,因为48小时内,还可以把TDD/BDD写的很完善的人,那这个人或团队,真的是在用TDD/BDD去进行开发实践,已经变成他们的编程习惯了, 那么他们的作品就应该是一个优秀的TDD/BDD案例。

Comments

comments powered by Disqus