Ruby on Rails 单元测试

Ruby on Rails 单元测试

为什么要写测试文件?

软件开发中,一个重要的环节就是编写测试文件,对代码进行单元测试,确保程序各部分功能执行正确。但是,这一环节很容易被我们轻视,认为进行单元测试的必要性不大,最主要的一个原因是需要耗费大量时间。显然,这种观点是很浅显的,Michael Hartl 在他的《Ruby on Rails 教程——通过 Rails 学习 Web 开发》中指出编写自动化测试主要有三个好处:

  1. 测试能避免回归(regression)问题,即由于某些原因之前能用的功能不能用了;
  2. 有测试在,重构(改变实现方式,但功能不变)时更有自信;
  3. 测试是应用代码的客户,因此可以协助我们设计,以及决定如何与系统的其他组件交互。

也就是说,我们也许能够保证第一遍书写的代码的正确性,但我们难以保证日后对代码进行数次迭代更新,优化之后,它仍然能够保持最初的正确性。因为随着设计的不断深入,我们应对的情况会越来越复杂,这时候单元测试的重要性就显得尤为重要,代码的正确性很多时候就要通过单元测试来维持。

何时进行测试,何时不需要测试?

同上,Michael 在他的 Rails 教程中指出:

  • 与应用代码相比,如果测试代码特别简短,倾向于先编写测试
  • 如果对想实现的功能不是特别清楚,倾向于先编写应用代码,然后再编写测试,并改进实现方式
  • 安全是头等大事,保险起见,要为安全相关的功能先编写测试
  • 只要发现一个问题,就编写一个测试重现这种问题,避免回归,然后再编写应用代码修正问题
  • 尽量不为以后可能修改的代码(例如 HTML 结构的细节)编写测试
  • 重构之前要编写测试,集中测试容易出错的代码。

以此次 Rails 开发为例,我们主要编写了控制器和模型测试文件。

Ruby on Rails 的模型测试

在 Rails 中编写测试非常方便,生成模型和控制器时,已经在 ./test 路径下生成了各种测试代码骨架。即便是大范围重构后,只需运行测试就能确保实现了所需功能。Rails 中的测试还可以模拟浏览器请求,无需打开浏览器就能测试程序的响应。

test 文件夹内容如下:

$ ls -F test
controllers/  helpers/    mailers/    test_helper.rb
fixtures/    integration/  models/

models 文件夹存放模型测试,controllers 文件夹存放控制器测试,integration 文件夹存放多个控制器之间交互的测试。fixtures 文件夹中存放固件,用于提供初始的测试数据,固件相互独立,一个文件对应一个模型,使用 YAML 格式编写。在运行测试之前,Rails 会把预先定义好的数据导入测试数据库。

test_helper.rb 文件中保存测试的默认设置。

以一次测试为例,test/controllers/club_management_controller_test.rb 中,测试新增的社团活动评价功能:

test ‘should evaluate activity‘ do
    # 根据fixtures中的yaml文件获取活动信息
    activity = activities(:basketball)
    # 定义评价信息
    club = clubs(:basketball_club)
    reason = ‘nice‘
    suggestion = ‘no suggestion‘
    # 向相应的路由post评价请求,将评价信息作为参数传递
    put activity_evaluate_path(club_id: club.id, activity_id: activity.id),
        params: { rank: 233, reason: reason, suggestion: suggestion }
    # 断言HTML响应,200表示操作应成功
    assert_response 200
    puts JSON.parse(@response.body)[‘data‘]
    # 模拟浏览器响应,应该与上面传递的信息一致
    assert_equal 10, JSON.parse(@response.body)[‘data‘][‘rank‘]
    assert_equal reason, JSON.parse(@response.body)[‘data‘][‘reason‘]
    assert_equal suggestion, JSON.parse(@response.body)[‘data‘][‘suggestion‘]
    put activity_evaluate_path(club_id: club.id, activity_id: activity.id),
        params: { rank: -8 }
    assert_response 200
    assert_equal 0, JSON.parse(@response.body)[‘data‘][‘rank‘]
  end

在此次测试中,activityclub 数据均已在 fixtures/*.yml 中定义好,fixtures/activities.yml 如下

basketball:
  name: 篮球赛
  start_time: 2100-04-13 03:04:48
  end_time: 2100-04-13 03:04:48
  act_date: 2020-05-20
  beg_time: 2020-05-20 13:14:02
  fin_time: 2020-05-20 13:14:10
  position: MyString
  description: MyText
  max_people_limit: 1
  need_enroll: true
  review_state: 0

fixtures/clubs.yml 如下

basketball_club:
  name: 篮球社
  english_name: basketball_club
  introduction: play basketball
  level: 3
  club_category: sport
  is_related_to_wechat: false
  tags_json: ‘{}‘
  has_activities_applying: 0
  has_activities_unevaluated: 0

同时,需要定义社团和活动的所属关系,在 fixtures/club_to_activities.yml 中:

···
five:
  club: basketball_club
  activity: basketball

之所以需要定义这种关系,是因为活动不能架空,活动应该有其相应的举办社团。我们在对活动进行操作时,这两项是必不可少的,社团和活动都要存在。Rails 为控制器提供了这种逻辑检验方法 before_action ,在 app/controllers/club_management_controller.rb 中:

before_action :_find_club, only:
      %i[club_profile club_update activity_index activity_create activity_profile activity_update activity_evaluate article_index article_create article_profile article_update activity_review]
  before_action :_find_activity, only: %i[activity_profile activity_update activity_evaluate activity_review]
private def _find_activity
	# 寻找活动的代码段
end
private def _find_club
	# 寻找社团的代码段
end

这段代码的意义已经在英文命名中体现出来了,只有在进行 [···] 这些操作之前时才执行 find 方法,从而保证逻辑的正确性。这种检验方法也使得我们不用每一次都手动调用 find 方法再进行判断,方便快捷又清晰。

但是,现在还没有万事大吉,因为还没有登录,没有任何权限,无法进行操作。同上,Rails 在 test 中也为我们提供了 setup 方法,我们只需要重写此方法就可以实现每个 test 块之前的设置工作,setup 方法定义在 Ruby26-x64/lib/ruby/gems/2.6.0/gems/minitest-5.14.1/lib/minitest/test.rb 中定义(不同版本的 ruby 可能路径不同):

##
# Runs before every test. Use this to set up before each test
# run.

def setup; end

app/controllers/club_management_controller.rb 中重写此方法进行管理员登录:

def setup
    @user = users(:three)
    post session_login_path, params:
        {
          username: @user.email,
          password: ‘password‘
        }
  end

其中 fixtures/users.yml 文件如下:

three:
  username: zkk
  nickname: nick
  real_name: zkr
  student_id: 16029999
  tag: abcd
  role: 3
  password_digest: <%= User.digest(‘password‘) %>
  remember_digest: <%= User.digest(‘password‘) %>
  open_id: 3
  union_id: 3
  wxid: c3
  session_key: 1001
  college_id: 1
  email: 
  political_status_id: 1
  gender: 1
  phone_number: 1334234321
  id_number: 610104199803281547
  status: 1
  avatar_url: https://test.jpg

这时再执行 rails test 就可以开始测试。

上面的一些 .yml 文件中,一些数据不是很规范,但只要能够保证逻辑、格式正确,能够正确使用就可以,如果在此之上进行更规范地编写也是一种可取的做法。

Rails 测试中的断言

在上述测试文件中,用到了许多 assert 的方法,如 assert_equal 判断两个变量是否相等, assert_response 判断 HTML 响应,这也是 Rails 为我们提供的一些便利,其余一些 assert 方法如下所示:

AssertionPurpose
assert( test, [msg] )Ensures that test is true.
refute( test, [msg] )Ensures that test is false.
assert_equal( expected, actual, [msg] )Ensures that expected == actual is true.
refute_equal( expected, actual, [msg] )Ensures that expected != actual is true.
assert_same( expected, actual, [msg] )Ensures that expected.equal?(actual) is true.
refute_same( expected, actual, [msg] )Ensures that expected.equal?(actual) is false.
assert_nil( obj, [msg] )Ensures that obj.nil? is true.
refute_nil( obj, [msg] )Ensures that obj.nil? is false.
assert_match( regexp, string, [msg] )Ensures that a string matches the regular expression.
refute_match( regexp, string, [msg] )Ensures that a string doesn‘t match the regular expression.
assert_in_delta( expecting, actual, [delta], [msg] )Ensures that the numbers expected and actual are within delta of each other.
refute_in_delta( expecting, actual, [delta], [msg] )Ensures that the numbers expected and actual are not within delta of each other.
assert_throws( symbol, [msg] ) { block }Ensures that the given block throws the symbol.
assert_raises( exception1, exception2, ... ) { block }Ensures that the given block raises one of the given exceptions.
assert_nothing_raised( exception1, exception2, ... ) { block }Ensures that the given block doesn‘t raise one of the given exceptions.
assert_instance_of( class, obj, [msg] )Ensures that obj is an instance of class.
refute_instance_of( class, obj, [msg] )Ensures that obj is not an instance of class.
assert_kind_of( class, obj, [msg] )Ensures that obj is or descends from class.
refute_kind_of( class, obj, [msg] )Ensures that obj is not an instance of class and is not descending from it.
assert_respond_to( obj, symbol, [msg] )Ensures that obj responds to symbol.
refute_respond_to( obj, symbol, [msg] )Ensures that obj does not respond to symbol.
assert_operator( obj1, operator, [obj2], [msg] )Ensures that obj1.operator(obj2) is true.
refute_operator( obj1, operator, [obj2], [msg] )Ensures that obj1.operator(obj2) is false.
assert_send( array, [msg] )Ensures that executing the method listed in array[1] on the object in array[0] with the parameters of array[2 and up] is true. This one is weird eh?
flunk( [msg] )Ensures failure. This is useful to explicitly mark a test that isn‘t finished yet.

除此之外还有一些更加精确的断言方法,详细可以参考有关Rails test的官方手册

A Guide to Testing Rails Applications

测试覆盖率

使用 simplecov,只需要在 Gemfile 文件中为 test 环境添加一行

gem ‘simplecov‘, ‘~>0.9.0‘

再执行 ./bin/bundle install 就可以安装 gem 包。

如上所说 test_helper.rb 文件中保存测试的默认设置,我们只需要在其中加入对包的引入与启动即可:

require ‘simplecov‘
SimpleCov.start

再次运行 rails test 时会在测试结束时显示覆盖率,并在 coverage 文件夹下生成覆盖信息 coverage/index.html,页面如下图所示:

Ruby on Rails 单元测试

能够看到各个文件的覆盖信息,也可以查看具体文件覆盖信息,如下图所示:

Ruby on Rails 单元测试

总结

Rails 无论是开发还是测试,都为我们提供了许多便利之处,但如何学会并运用这些便利,是 Rails 学习的一大难点。另外,Ruby 这门语言的更新之快,也让它难以捉摸,它的版本太多,有时最新的版本和之前的并不兼容,也造成了一定的学习困难。总而言之,Ruby 确实是一门博大精深的语言。

相关推荐