高效的单元测试Rails该怎样进行

在笔者开发的系统中，有大量的数据需要分析，不仅要求数据分析准确，而且对速度也有一定的要求的。没有写测试代码之前，笔者用几个很大的方法来实现这种需求。结果可想而知，代码繁杂，维护困难，难于扩展。借业务调整的机会，笔者痛定思痛，决定从测试代码做起，并随着不断地学习和应用，慢慢体会到测试代码的好处。

  • 改变思路：能做到从需求到代码的过程转换，逐步细化；
  • 简化代码：力图让每个方法都很小，只专注一件事；
  • 优化代码：当测试代码写不出来，或者需要写很长的时候，说明代码是有问题的，是可以被分解的，需要进一步优化；
  • 便于扩展：当扩展新业务或修改旧业务时，如果测试代码没有成功，则说明扩展和修改不成功；
  • 时半功倍：貌似写测试代码很费时，实际在测试、部署和后续扩展中，测试代码将节省更多的时间。

环境搭建

笔者采用的测试环境是比较流行通用的框架：RSpec + Factory Girl，并用autotest自动工具。RSpec是一种描述性语言，通过可行的例子描述系统行为，非常容易上手，测试用例非常容易理解。Factory Girl可以很好的帮助构造测试数据，免去了自己写fixture的烦恼。Autotest能自动运行测试代码，随时检测测试代码的结果，并且有很多的插件支持，可以让测试结果显示的很炫。

第一步 安装rspec和rspec-rails

在命令行中执行如下命令：

 
 
 
    
  
  
  
  1. $ sudo gem install rspec v = 1.3.0  
    2.   
  
  
  2. $ sudo gem install rspec-rails v = 1.3.2 
    3.

安装完成后，进入rails应用所在的目录，运行如下脚本，生成spec测试框架：

 
 
 
    
  
  
  
  1. $ script/generate rspec   
    2.   
  
  
  2. exists lib/tasks  
    3.   
  
  
  3. identical lib/tasks/rspec.rake  
    4.   
  
  
  4. identical script/autospec  
    5.   
  
  
  5. identical script/spec  
    6.   
  
  
  6. exists spec  
    7.   
  
  
  7. identical spec/rcov.opts  
    8.   
  
  
  8. identical spec/spec.opts  
    9.   
  
  
  9. identical spec/spec_helper.rb 
    10.

第二步 安装factory-girl

在命令行中执行如下命令：

 
 
 
    
  
  
  
  1. $ sudo gem install factory-girl 
    2.

在config/environment/test.rb中，加入factory-girl这个gem：

 
 
 
    
  
  
  
  1. config.gem "factory_girl" 
    2.

在spec/目录下，增加一个factories.rb的文件，用于所有预先定义的model工厂。

第三步 安装autotest

在命令行中执行如下命令：

 
 
 
    
  
  
  
  1. $ sudo gem install ZenTest  
    2.   
  
  
  2. $ sudo gem install autotest-rails 
    3.

然后设置与RSpec的集成，在rails应用的目录下，运行如下的命令，就可以显示测试用例的运行结果。

 
 
 
    
  
  
  
  1. RSPEC=true autotest or autospec 
    2.

在自己的home目录下，增加一个.autotest设置所有的Rails应用的autotest插件。当然，也可以把这个文件加到每个应用的根目录下，这个文件将覆盖home目录下的文件设置。autotest的插件很多，笔者用到如下的plugin：

 
 
 
    
  
  
  
  1. $ sudo gem install autotest-growl  
    2.   
  
  
  2. $ sudo gem install autotest-fsevent  
    3.   
  
  
  3. $ sudo gem install redgreen 
    4.

设置.autotest文件，在.autotest中，加入如下代码。

 
 
 
    
  
  
  
  1. require 'autotest/growl'   
    2.   
  
  
  2. require 'autotest/fsevent'   
    3.   
  
  
  3. require 'redgreen/autotest'   
    4.   
  
  
  4. Autotest.add_hook :initialize do |autotest|  
    5.   
  
  
  5. %w{.git .svn .hg .DS_Store ._* vendor tmp log doc}.each do |exception|  
    6.   
  
  
  6. autotest.add_exception(exception)  
    7.   
  
  
  7. end  
    8.   
  
  
  8. end 
    9.

#p#

测试经验

安装了必要的程序库以后，就可以写测试代码了。本例中，所有应用都是在Rails 2.3.4上开发的，RSpec采用的是1.3.0的版本。为了很好的说明问题，我们假定这样的需求：判断一个用户在一个时间段内是否迟到。写测试代码时都是遵循一个原则，只关心输入和输出，具体的实现并不在测试代码的考虑范围之内，是行为驱动开发。根据这个需求，我们将会设计方法absence_at(start_time,end_time)，有两个输入值start_time和end_time以及一个输出值，类型是boolean。对应的测试代码如下：

 
 
 
    
  
  
  
  1. describe "User absence or not during [start_time,end_time]" do  
    2.   
  
  
  2. before :each do   
    3.   
  
  
  3. @user = Factory(:user)  
    4.   
  
  
  4. end 
    5.   
  
  
  5. it "should return false when user not absence " do  
    6.   
  
  
  6. start_time = Time.utc(2010,11,9,12,0,0,0)  
    7.   
  
  
  7. end_time = Time.utc(2010,11,9,12,30,0)   
    8.   
  
  
  8. @user.absence_at(start_time,end_time).should be_false  
    9.   
  
  
  9. end 
    10.   
  
  
  10. it "should return true when user absence " do  
    11.   
  
  
  11. start_time = Time.utc(2010,11,9,13,0,0,0)  
    12.   
  
  
  12. end_time = Time.utc(2010,11,9,13,30,0)   
    13.   
  
  
  13. @user.absence_at(start_time,end_time).should be_ture  
    14.   
  
  
  14. end 
    15.   
  
  
  15. end 
    16.

测试代码已经完成。至于absence_at方法我们并不关心它的实现，只要这个方法的结果能让测试代码运行结果正确就可以。在此测试代码的基础上，就可以大胆地去完成代码，并根据测试代码的结果不断修改代码直到所有测试用例通过。

Stub的使用

写测试代码，最好首先从model开始。因为model的方法能很好与输入输出的原则吻合，容易上手。最初的时候，你会发现mock和stub很好用，任何的对象都可以mock，并且在它的基础上可以stub一些方法，省去构造数据的麻烦，一度让笔者觉得测试代码是如此美丽，一步步的深入，才发现自己陷入了stub的误区。还是引用上面的例子，我们的代码实现如下：

 
 
 
    
  
  
  
  1. class User < ActiveRecord::Base 
    2.   
  
  
  2. def absence_at(start_time,end_time)   
    3.   
  
  
  3. return false if have_connection_or_review?(start_time,end_time)  
    4.   
  
  
  4. return (login_absence_at?(start_time,end_time) ? true : false)   
    5.   
  
  
  5. end  
    6.   
  
  
  6. end 
    7.

按照最初写测试代码的思路，本方法中存在三种情况，即需要三个用例，而且还调用了其他两个方法，需要对他们进行stub，于是就有了下面的测试代码。记得当时完成后还很兴奋，心中还想：这么写测试代码真有趣。

 
 
 
    
  
  
  
  1. before(:each) do  
    2.   
  
  
  2. @user = User.new  
    3.   
  
  
  3. end  
    4.   
  
  
  4. describe "method " do   
    5.   
  
  
  5. s = Time.now  
    6.   
  
  
  6. e = s + 30.minutes  
    7.   
  
  
  7. # example one  
    8.   
  
  
  8. it "should be false when user have interaction or review" do  
    9.   
  
  
  9. @user.stub!(:have_connection_or_review?).with(s,e).and_return(true)  
    10.   
  
  
  10. @user.absence_at(s,e).should be_false  
    11.   
  
  
  11. end  
    12.   
  
  
  12. # example two  
    13.   
  
  
  13. it "should be true when user has no interaction and he no waiting at platform" do  
    14.   
  
  
  14. @user.stub!(:have_connection_or_review?).with(s,e).and_return(false)  
    15.   
  
  
  15. @user.stub!(:login_absence_at?).with(s,e).and_return(true)  
    16.   
  
  
  16. @user.absence_at(s,e).should be_true  
    17.   
  
  
  17. end  
    18.   
  
  
  18. # example three  
    19.   
  
  
  19. it "should be false when user has no interaction and he waiting at platform" do  
    20.   
  
  
  20. @user.stub!(:have_connection_or_review?).with(s,e).and_return(false)  
    21.   
  
  
  21. @user.stub!(:login_absence_at?).with(s,e).and_return(false)  
    22.   
  
  
  22. @user.absence_at(s,e).should be_false  
    23.   
  
  
  23. end   
    24.   
  
  
  24. end 
    25.

上面的测试代码，是典型把代码的实现细节带到了测试代码中，完全是本末倒置的。当然这个测试代码运行的时候，结果都是正确的。那是因为用stub来假定所有的子方法都是对的，但是如果这个子方法have_connection_or_review?发生变化，它不返回boolean值，那么将会发生什么呢？这个测试代码依然正确，可怕吧！这都没有起到测试代码的作用。

另外，如果是这样，我们不仅要修改have_connection_or_review?的测试代码，而且还要修改absence_at的测试代码。这不是在增大代码维护量吗？

相比而言，不用stub的测试代码，不用修改，如果Factory的数据没有发生变化，那么测试代码的结果将是错误的，因为have_connection_or_review?没有通过测试，导致absence_at方法无法正常运行。

其实stub主要是mock一些本方法或者本应用中无法得到的对象，比如在tech_finish?方法中，调用了一个file_service来获得Record对象的所有文件，在本方法测试代码运行过程中，无法得到这个service，这时stub就起作用了：

 
 
 
    
  
  
  
  1. class A < ActiveRecord::Base 
    2.   
  
  
  2. has_many :records  
    3.   
  
  
  3. def tech_finish?  
    4.   
  
  
  4. self.records.each do |v_a|  
    5.   
  
  
  5. return true if v_a.files.size == 5  
    6.   
  
  
  6. end  
    7.   
  
  
  7. return false  
    8.   
  
  
  8. end  
    9.   
  
  
  9. end  
    10.   
  
  
  10. class Record < ActiveRecord::Base 
    11.   
  
  
  11. belongs_to :a  
    12.   
  
  
  12. has_files # here is a service in gem  
    13.   
  
  
  13. end 
    14.

所对应的测试代码如下：

 
 
 
    
  
  
  
  1. describe "tech_finish?" do  
    2.   
  
  
  2. it "should return true when A’s records have five files" do  
    3.   
  
  
  3. record = Factory(:record)  
    4.   
  
  
  4. app = Factory(:a,:records=>[record])  
    5.   
  
  
  5. record.stub!(:files).and_return([1,2,3,4,5])   
    6.   
  
  
  6. app.tech_finish?.should == true  
    7.   
  
  
  7. end  
    8.   
  
  
  8. it "should return false when A’s records have less five files" do  
    9.   
  
  
  9. record = Factory(:record)  
    10.   
  
  
  10. app = Factory(:a,:records=>[record])  
    11.   
  
  
  11. record.stub!(:files).and_return([1,2,3,5])   
    12.   
  
  
  12. app.tech_finish?.should == false  
    13.   
  
  
  13. end  
    14.   
  
  
  14. end 
    15.

Factory的使用

有了这个工厂，可以很方便的构造不同的模拟数据来运行测试代码。还是上面的例子，如果要测试absence_at方法，涉及到多个model：

  • HistoryRecord：User的上课记录
  • Calendar：User的课程表
  • Logging：User的日志信息

如果不用factory-girl构造测试数据，我们将不得不在fixture构造这些测试数据。在fixture构造的数据无法指定是那个测试用例使用，但是如果用Factory的话，可以为这个方法专门指定一组测试数据。

 
 
 
    
  
  
  
  1. Factory.define :user_absence_example,:class => User do |user|  
    2.   
  
  
  2. user.login "test"  
    3.   
  
  
  3. class << user 
    4.   
  
  
  4. def default_history_records  
    5.   
  
  
  5. [Factory.build(:history_record,:started_at=>Time.now),  
    6.   
  
  
  6. Factory.build(:history_record,:started_at=>Time.now)]  
    7.   
  
  
  7. end  
    8.   
  
  
  8. def default_calendars  
    9.   
  
  
  9. [Factory.build(:calendar),  
    10.   
  
  
  10. Factory.build(:calendar)]   
    11.   
  
  
  11. end  
    12.   
  
  
  12. def default_loggings  
    13.   
  
  
  13. [Factory.build(:logging,:started_at=>1.days.ago),  
    14.   
  
  
  14. Factory.build(:logging,:started_at=>1.days.ago)]  
    15.   
  
  
  15. end  
    16.   
  
  
  16. end  
    17.   
  
  
  17. user.history_records {default_history_records}  
    18.   
  
  
  18. user.calendars {default_calendars}  
    19.   
  
  
  19. user.loggings {default_loggings}  
    20.   
  
  
  20. end 
    21.

这个测试数据的构造工厂，可以放在factories.rb文件中，方便其他测试用例使用，也可以直接放到测试文件的before中，仅供本测试文件使用。通过factory的构造，不仅可以为多个测试用例共享同一组测试数据，而且测试代码也简洁明了。

 
 
 
    
  
  
  
  1. before :each do  
    2.   
  
  
  2. @user = Factory.create(:user_absence_example)  
    3.   
  
  
  3. end 
    4.

#p#

Readonly的测试

在笔者的系统中，大量使用了acts_as_readonly，从另外一个数据库来读取数据。由于这些model并不在本系统中，所以当用Factory构造测试数据的时候，总会有问题。虽然也可以使用mock来达到这个目的，但是由于mock的局限性，还是无法灵活的满足构造测试数据的需要。为此，扩展了一些代码，使得这些model依然可以测试。核心思想则是，根据配置文件的设置，将对应的readonly的表创建在测试数据库，这个操作在运行测试之前执行，这样就达到与其他model一样的效果。site_config配置文件中，关于readonly的配置格式如下：

 
 
 
    
  
  
  
  1. readonly_for_test:  
    2.   
  
  
  2. logings:  
    3.   
  
  
  3. datetime: created_at  
    4.   
  
  
  4. string: status  
    5.   
  
  
  5. integer: trainer_id 
    6.

Gem的测试

Gem在Rails中被广泛使用，而且是最基础的东西，因此它的准确无误就显得更加重要。在不断实践的基础上，笔者所在的团队总结出一种用spec测试gem的方法。假设我们要测试的gem是platform_base，步骤如下：

1. 在gem的根目录下创建一个目录spec（路径为platform_base/spec）。

2. 在gem的根目录下创建文件Rakefile（路径为platform_base/Rakefile），内容如下：

 
 
 
    
  
  
  
  1. require 'rubygems'  
    2.   
  
  
  2. require 'rake'  
    3.   
  
  
  3. require 'spec/rake/spectask'  
    4.   
  
  
  4. Spec::Rake::SpecTask.new('spec') do |t|  
    5.   
  
  
  5. t.spec_opts = ['--options', "spec/spec.opts"]  
    6.   
  
  
  6. t.spec_files = FileList['spec/**/*_spec.rb']  
    7.   
  
  
  7. end 
    8.

3. 文件在spec目录下创建spec.opts（路径为platform_base/spec/spec.opts），内容如下：

 
 
 
    
  
  
  
  1. --colour  
    2.   
  
  
  2. --format progress  
    3.   
  
  
  3. --loadby mtime  
    4.   
  
  
  4. --reverse 
    5.

4. 在spec目录下，创建一个Rails app，名为test_app。这个新应用需要有spec目录和spec_helper.rb文件。

5. 为了保持简化，把这个新app（test_app）整理一下，删除vendor和public目录，最终的结构如下：

 
 
 
    
  
  
  
  1. test_app  
    2.   
  
  
  2. |- app  
    3.   
  
  
  3. |- config  
    4.   
  
  
  4. | |- environments  
    5.   
  
  
  5. | |- initializers  
    6.   
  
  
  6. | |- app_config.yml  
    7.   
  
  
  7. | |- boot.rb  
    8.   
  
  
  8. | |- database.yml  
    9.   
  
  
  9. | |- environment.rb  
    10.   
  
  
  10. | \- routes.rb  
    11.   
  
  
  11. |- db  
    12.   
  
  
  12. | \- test.sqlite3  
    13.   
  
  
  13. |- log  
    14.   
  
  
  14. \- spec  
    15.   
  
  
  15. \- spec_helper.rb 
    16.

6. 在config/environment.rb配置文件中，增加如下代码：

 
 
 
    
  
  
  
  1. Rails::Initializer.run do |config|  
    2.   
  
  
  2. config.gem 'rails_platform_base'  
    3.   
  
  
  3. end 
    4.

7. 在platform_base/spec/目录下增加helpers_spec.rb文件，内容如下：

 
 
 
    
  
  
  
  1. require File.join(File.dirname(__FILE__), 'test_app/spec/spec_helper')  
    2.   
  
  
  2. describe "helpers" do  
    3.   
  
  
  3. describe "url_of" do  
    4.   
  
  
  4. before do  
    5.   
  
  
  5. Rails.stub!(:env).and_return("development")  
    6.   
  
  
  6. @controller = ActionController::Base.new  
    7.   
  
  
  7. end 
    8.   
  
  
  8. it "should get url from app's configration" do  
    9.   
  
  
  9. @controller.url_of(:article, :comments, :article_id => 1).should == "http://www.idapted.com/article/articles/1/comments" 
    10.   
  
  
  10. @controller.url_of(:article, :comments, :article_id => 1, :params=>{:category=>"good"}).should == "http://www.idapted.com/article/articles/1/comments?category=good" 
    11.   
  
  
  11. end 
    12.   
  
  
  12. end 
    13.   
  
  
  13. end 
    14.

至此，准备工作已经就绪，可以在platform_base目录下，运行rake spec来进行测试，当然现在什么都不会发生，因为还没有测试代码呢。本方法中，最关键的就是下面的require语句，不仅加载了Rails environment，而且把gem在test_app中使用并测试。

 
 
 
    
  
  
  
  1. require File.join(File.dirname(__FILE__), 'test_app/spec/spec_helper') 
    2.

#p#

Controller的测试

对于controller的测试，一般来说比较简单，基本是三段式：初始化参数、请求方法、返回render或者redirect_to。如下例中，对某个controller的index方法的测试：

 
 
 
    
  
  
  
  1. describe "index action" do  
    2.   
  
  
  2. it "should render report page with the current month report" do  
    3.   
  
  
  3. controller.stub!(:current_user).and_return(@user)  
    4.   
  
  
  4. get :index,{:flag => “test”}  
    5.   
  
  
  5. response.should render_template("index")  
    6.   
  
  
  6. end  
    7.   
  
  
  7. end 
    8.

有些controller会设置session或者flash，这时的测试代码就一定要检查这个值设置的是否正确，而且还需要增加测试用例来覆盖不同的值，这样才能对方法进行全面的测试。如下例：

 
 
 
    
  
  
  
  1. describe "create action" do  
    2.   
  
  
  2. it "should donot create new user with wrong params" do  
    3.   
  
  
  3. post :create  
    4.   
  
  
  4. response.should redirect_to(users_path)  
    5.   
  
  
  5. flash[:notice].should == "Create Fail!"  
    6.   
  
  
  6. end  
    7.   
  
  
  7.  
    8.   
  
  
  8. it "should create a new user with right params" do  
    9.   
  
  
  9. post :create, {:email => "abc@eleutian.com"}  
    10.   
  
  
  10. response.should redirect_to(users_path)  
    11.   
  
  
  11. flash[:notice].should == "Create Successful!"  
    12.   
  
  
  12. end  
    13.   
  
  
  13. end 
    14.

同时，也需要对controller的assigns进行测试，以保证返回正确的数据。如下例：

 
 
 
    
  
  
  
  1. before(:each) do  
    2.   
  
  
  2. @course = Factory(:course)  
    3.   
  
  
  3. end   
    4.   
  
  
  4. describe "show action" do  
    5.   
  
  
  5. it "should render show page when flag != assess and success" do   
    6.   
  
  
  6. get :show, :id => @course.id, :flag =>"test"  
    7.   
  
  
  7. response.should render_template("show")  
    8.   
  
  
  8. assigns[:test_paper].should == @course  
    9.   
  
  
  9. assigns[:flag].should == "test"  
    10.   
  
  
  10. end  
    11.   
  
  
  11. it "should render show page when flag == assess and success" do  
    12.   
  
  
  12. get :show, :id => @course.id, :flag =>"assess"  
    13.   
  
  
  13. response.should render_template("show")  
    14.   
  
  
  14. assigns[:test_paper].should == @course  
    15.   
  
  
  15. assigns[:flag].should == "assess"  
    16.   
  
  
  16. end   
    17.   
  
  
  17. end 
    18.

View的测试

View的测试代码写的比较少，基本上是把核心的view部分集成到controller中来测试。主要用integrate_views方法。如下例：

 
 
 
    
  
  
  
  1. describe AccountsController do  
    2.   
  
  
  2. integrate_views  
    3.   
  
  
  3. describe "index action" do  
    4.   
  
  
  4. it "should render index.rhtml" do  
    5.   
  
  
  5. get :index  
    6.   
  
  
  6. response.should render_template("index")  
    7.   
  
  
  7. response.should have_tag("a[href=?]",new_account_path)  
    8.   
  
  
  8. response.should have_tag("a[href=?]",new_session_path)  
    9.   
  
  
  9. end  
    10.   
  
  
  10. end  
    11.   
  
  
  11. end 
    12.

总结展望

在写测试代码的时候，并不一定要事无巨细，有些比较简单的方法以及Rails的内部的方法，如named_scope，就完全没有必要测试。本文中，只介绍了用rspec写单元测试的代码，对于集成测试没有涉及，这也是今后努力的一个方向。

另外，用cumumber + rspec + webrat的BDD开发模式也是相当不错的。尤其是cumumber对需求的描述，完全可以用它来做需求分析。

分享文章：高效的单元测试Rails该怎样进行
URL分享：http://www.shufengxianlan.com/qtweb/news8/452358.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

定制网站知识

各行业网站

西云服务器托管　　 　蓬安网站建设　　 　简阳网站制作　　 　做网站价格　　 　高防机房　　 　温江做网站公司　　 　成都响应式网站建设　　 　达州电信机房　　 　成都IDC机房托管　　 　域名注册　　 　网页改版　　 　腾讯云虚拟主机　　 　成都SEO公司　　 　高端定制网站建设　　 　复盛机电设备安装　　 　保温橡塑管　　 　酒柜书柜鞋柜定制　　 　成都广告制作　　 　红光高低压开关厂　　 　高端网站建设