RSpec 是一个非常棒的工具。它在 BDD 流程的开发中被用来写高可读性的测试,引导并验证你开发的应用程序。

网上有很多资源告诉你 RSpec 能“做什么”,但却很少有人讨论如何用它编写出高质量的测试用例。

Better Specs 通过收集其他开发者经年累月积攒的绝大部分“最佳实践”来尝试着来填补这之间的鸿沟。

如何来描述 (describe) 你的 method

首先要清楚你要描述的是什么类型的方法。用 Ruby 文档的一个惯例举例,提到类方法时使用.(或者::),提到实例方法的时候用#来描述。

bad

describe 'the authenticate method for user' do
describe 'if the user is an admin' do

good

describe '.authenticate' do
describe '#admin?' do

探讨这条最佳实践...

使用上下文环境 contexts

contexts 非常强大,它能让测试更清晰,有条理。在漫长的开发过程中,让你的测试一直保持高度的可读性。

bad

it 'has 200 status code if logged in' do
  response.should respond_with 200
end
it 'has 401 status code if not logged in' do
  response.should respond_with 401
end

good

context 'when logged in' do
  it { is_expected.to respond_with 200 }
end
context 'when logged out' do
  it { is_expected.to respond_with 401 }
end

在描述一个 context 时用 “when” 或者 “with” 作为开头

探讨这条最佳实践...

保持简洁的 description

一个测试的描述永远也不应该超过 40 个字符。如果超过了,那就应该用 context 来分割。

bad

it 'has 422 status code if an unexpected params will be added' do

good

context 'when not valid' do
  it { should respond_with 422 }
end

在这个例子中,我们用测试的期望 it { should respond_with 422 } 替换了描述中相关的 status code。 如果你用 rspec filename 执行这个测试,你依然能得到非常可读的测试报告。

formatted output

when not valid
  it should respond with 422

探讨这条最佳实践...

唯一的测试条件

“唯一的测试条件”可以被宽泛的定义为“每一个测试都应该只有一个断言”。 这样做的能帮助你找到可能的问题,直接前往失败的测试,并且让你的代码具有可读。

在独立的单元测试中,你希望每一个具体的测试都只定义一个而且是只有一个行为。多重的测试期望条件在同一个具体测试中 说明你可能定义了多个行为。

不过,在像那些涉及了数据库,外部 Web Service,或者从一个系统到另一个系统的测试中,你可能会 消耗大量的资源来不断的重复一些准备工作,就因为要进行不同的单一条件测试。在这些非常消耗时间的测试中, 定义多个行为是可以接受的。

good (isolated)

it { should respond_with_content_type(:json) }
it { should assign_to(:resource) }

good (not isolated)

it 'creates a resource' do
  response.should respond_with_content_type(:json)
  response.should assign_to(:resource)
end
探讨这条最佳实践...

测试所有的可能

测试是件好事,但如果你不进行边界测试,测试就不会真正的有效。有效和无效的边界情形都需要被测试,用下面的例子来做示范。

destroy action

before_filter :find_owned_resources
before_filter :find_resource

def destroy
  render 'show'
  @consumption.destroy
end

对于这个例子来说,非常常见的错误就是只测试这个资源有没有被摧毁。但这个 action 至少还包括了两个边界情形:当这个资源 找不到的时候或者这个资源没有权限被摧毁。记得这个通用的原则:考虑所有可能的输入并对他们都进行测试。

bad

it 'shows the resource'

good

describe '#destroy' do

  context 'when resource is found' do
    it 'responds with 200'
    it 'shows the resource'
  end

  context 'when resource is not found' do
    it 'responds with 404'
  end

  context 'when resource is not owned' do
    it 'responds with 404'
  end
end

探讨这条最佳实践...

善用 subject

如果你有好几个测试都是用了同一个 subject,使用 subject{} 来避免重复。

bad

it { assigns('message').should match /it was born in belville/ }
it { assigns('message').creator.should match /topolino/ }

good

subject { assigns('message') }
it { should match /it was born in billville/ }

RSpec 也可以给 subject 命名。

good

subject(:hero) { hero.first }
it "carries a sword" do
  hero.equipment.should include "sword"
end

了解更多关于 RSpec Subject.

探讨这条最佳实践...

使用 let 和 let!

当你需要给一个变量赋值时,使用 let 而不是 before 来创建这个实例变量。let 采用了 lazy load 的机制,只有在第一次用到的时候才会加载,然后就被缓存,直到测试结束。 这里有一个讲的非常好非且有深度的描述什么 是 let 的帖子 Stackoverflow Answer

bad

describe '#type_id' do
  before { @resource = FactoryGirl.create :device }
  before { @type     = type.find @resource.type_id }

  it 'sets the type_id field' do
    @resource.type_id.should equal(@type.id)
  end
end

good

describe '#type_id' do
  let(:resource) { FactoryGirl.create :device }
  let(:type)     { type.find resource.type_id }

  it 'sets the type_id field' do
    resource.type_id.should equal(type.id)
  end
end

测试时用 let 初始化的行为会以 lazy load 的方式被加载。

good

context 'when updates a not existing property value' do
  let(:properties) { { id: settings.resource_id, value: 'on'} }

  def update
    resource.properties = properties
  end

  it 'raises a not found error' do
    expect { update }.to raise_error Mongoid::Errors::DocumentNotFound
  end
end

如果你想让这个变量在定义的时候就被初始化,使用 let! 。这是一个在测试数据库查询或者 scope 语句是非常有用的技巧。

下面是一个 let 的实例。

good

# 这一段:
let(:foo) { Foo.new }

# 基本上和这一段完全等同
def foo
  @foo ||= Foo.new
end

了解更多关于 RSpec Let.

探讨这条最佳实践...

要不要 mock

对于 mock 使用的时机一直有争议。不要过度使用 mock,而是尽可能的测试真实的行为。 测试真实的行为在改善你们的程序流程时非常的有用。

good

# 模拟一个没有找到的资源
context "when not found" do
  before { resource.stub(:where).with(created_from: params[:id]).and_return(false) }
  it { should respond_with 404 }
end

mock 能加快你们测试的速度,但它真的很难上手。你必须要对他了解的很深才能正确的应用。 这里可以了解更多。

探讨这条最佳实践...

只创建你需要的数据

如果你曾经在一个中型(小型的也是)的项目工作过,你会发现跑测试真的是非常的沉重。如果你要解决这个问题, 你是不可能载入你不需要的数据的。如果你需要成打的数据或者记录,你可能已经错了。

good

describe "user"
  describe ".top" do
    before { FactoryGirl.create_list(:user, 3) }
    it { User.top(2).should have(2).item }
  end
end

探讨这条最佳实践...

取 factories,舍 fixtures

这个话题有点炒冷饭,但是还是值得被记住。不要使用 fixtures 是因为它们很难被控制和维护。 改用 factories 来减少冗长的数据准备过程。

bad

user = user.create(
  name: 'genoveffa',
  surname: 'piccolina',
  city: 'billyville',
  birth: '17 agoust 1982',
  active: true
)

good

user = FactoryGirl.create :user

还有一点很重要。当谈到单元测试的时候,最佳的实践是既不用 fixtures 也不用 factories。尽可能的把你的业务逻辑 放在那些不需要复杂的而又非常费时的 factories 或者 fixtures。这篇 文章 可以让你了解更多。

更多关于 FactoryGirl.

探讨这条最佳实践...

一目了然的 matcher

使用易读的或是 RSpec 自带的 matchers

bad

lambda { model.save! }.should raise_error Mongoid::Errors::DocumentNotFound

good

expect { model.save! }.to raise_error Mongoid::Errors::DocumentNotFound

探讨这条最佳实践...

共用的测试

写测试非常棒,你会因此变得越来越自信。但到后来你会开始看到重复的代码出现在各个地方。用共用的测试来 DRY 你的测试。

bad

describe 'get /devices' do
  let!(:resource) { FactoryGirl.create :device, created_from: user.id }
  let(:uri) { '/devices' }

  context 'when shows all resources' do
    let!(:not_owned) { FactoryGirl.create factory }

    it 'shows all owned resources' do
      page.driver.get uri
      page.status_code.should be(200)
      contains_owned_resource resource
      does_not_contain_resource not_owned
    end
  end

  describe '?start=:uri' do
    it 'shows the next page' do
      page.driver.get uri, start: resource.uri
      page.status_code.should be(200)
      contains_resource resources.first
      page.should_not have_content resource.id.to_s
    end
  end
end

good

describe 'get /devices' do

  let!(:resource) { FactoryGirl.create :device, created_from: user.id }
  let(:uri)       { '/devices' }

  it_behaves_like 'a listable resource'
  it_behaves_like 'a paginable resource'
  it_behaves_like 'a searchable resource'
  it_behaves_like 'a filterable list'
end

不过从我们的经验来看,共用的测试主要是用于 controller。因为 model 之间的行为迥异,他们(经常)没用太多共通的逻辑。

了解更多关于 RSpec 共用测试的例子.

探讨这条最佳实践...

测你所见

尽可能详尽的测试你的 Model 和程序的行为(集成测试)。不要为 Controller 去写那些复杂而又没用的测试。

我一开始测试我的项目的时候,我测的就是 Controller,现在我却不这么做了。 现在我只用 RSpec 和 Capybara 来写一些集成测试。为什么?因为我真的觉得你应该 测试那些你能看到的,而 Controller 测试对于我来说是多余的。你最终会发现,你大部分的测试 都是涉及到 Model。集成测试能被轻松的整理到共用的测试来构建清晰而又可读的测试。

这是一个在 Ruby 社区中非常开放的争论,而且两边都是有理有据。支持测试 Controller 的那一方 会告诉你集成测试并不能覆盖所有的情况,而且很慢。

但他们都错了。你可以很轻易的覆盖所有的情形,并且使用一些像 Guard 这样的自动化测试工具来跑一个个单独的测试。 这样你就可以在不停止你的工作流程的情况下闪电般的只运行那些你正需要的测试。

探讨这条最佳实践...

别用 should

do not use should when describing your tests. use the third person in the present tense. even better start using the new 当你在描述你的测试的时候,不要使用 should,使用第三人称现在时。更进一步,你可以使用新的 expectation 语法。

bad

it 'should not change timings' do
  consumption.occur_at.should == valid.occur_at
end

good

it 'does not change timings' do
  expect(consumption.occur_at).to equal(valid.occur_at)
end

the should_notthe should_clean 这两个 Gem 在 RSpec 中贯彻这条实践并清除那些以 should 开头的测试。

探讨这条最佳实践...

用 Guard 进行自动化测试

每次你修改了你的项目就要重新跑所有的测试用力真的是一种负担。这会消耗很多时间并且打断了你的工作。 使用 Guard 你可以自动化的运行那些和你正在修改的测试,Model,Controller 或者文件有关的测试。

good

bundle exec guard
这是一个有些基本加载规则的 Guardfile 的例子。

good

guard 'rspec', cli: '--drb --format fuubar --color', version: 2 do
  # 执行所有被修改的测试
  watch(%r{^spec/.+_spec\.rb$})
  # 执行与 lib 文件夹下有关联的文件被修改的测试
  watch(%r{^lib/(.+)\.rb$}) { |m| "spec/lib/#{m[1]}_spec.rb" }
  # 执行与被修改 Model 相关的测试
  watch(%r{^app/(.+)\.rb$}) { |m| "spec/#{m[1]}_spec.rb" }
  # 执行与被修改的 View 相关的测试
  watch(%r{^app/(.*)(\.erb|\.haml)$}) { |m| "spec/#{m[1]}#{m[2]}_spec.rb" }
  # 执行与被修改的 Controller 相关的集成测试
  watch(%r{^app/controllers/(.+)\.rb}) { |m| "spec/requests/#{m[1]}_spec.rb" }
  # 当 application_controller 被修改时执行所有的集成测试
  watch('app/controllers/application_controller.rb') { "spec/requests" }
end

Guard 虽然好用但是它还是无法满足你搜有的需求。有时候你的 TDD 工作流程需要一些能够测试你想要测试文件的快捷键来让它变得完美。 而在你需要 push 代码的时候用 rake task 来跑完整的测试。这里有些 给 Vim 用的快捷键配置

了解更多关于 Guard RSpec.

探讨这条最佳实践...

更快的测试(预载 Rails)

在你跑测试的时候,实际上整个 Rails 都是被加载了的。这会消耗很多时间,并且打断你的开发流程。 解决这个问题,我们可以使用像 ZeusSpin 或者 Spork这样的工具。 这些工具会预载你所有的不常会更改的库,但是每次都会重载 Controllers,Models,Views 和 factories 这些你经常更改的文件。

这里有一个 spec helper 的例子,还有一个 Guardfile 配置的例子,他们都基于 Spork。 通过这些设定,整个项目都会被重载如果一个预载的文件(比如 initializers)被修改。你执行单一 测试的速度将会非常非常快。

The drawback of using Spork is that it aggressively monkey-patches your code and you could lose some hours trying to understand why a file is not reloaded. If you have some code examples using Spin or any other solution 使用 Sport 的缺点是,它会非常强势的 monkey-patch 你的代码。你可能会在试图搞明白为什么 一个文件没有被重载的过程中浪费数个小时。如果你有使用 Spin 或者其他解决方案的代码例子, 请告诉我

这里有一个配置 Zeus 的 Guardfile。 spec_helper 不用被修改。但你在跑任何测试之前,必须先在命令行中执行 `zeus start` 来启动 zeus 的服务器。

虽然 Zeus 被没有采用像 Sport 那样激进的途径,但它主要的一个缺点是比较严格的使用要求:Ruby 1.9.3+ (建议使用 Ruby 2.0 中的 backported 垃圾回收机制)以及一个支持 FSEvents 或者 inotify 的操作系统。

很多不满意的人迁移到了这些方案。不过比起这些补救性质的工具,更好的办法是采用更好的设计, 并且刻意的只载入你需要的依赖和库。读 这个讨论来了解更多。

探讨这条最佳实践...

伪装 HTTP 请求

有时候你需要用到一些外部的服务。在你不能真的使用这些外部服务的时候你应该用类似 webmock 这样的工具来进行伪装。

good

context "with unauthorized access" do
  let(:uri) { 'http://api.lelylan.com/types' }
  before    { stub_request(:get, uri).to_return(status: 401, body: fixture('401.json')) }
  it "gets a not authorized notification" do
    page.driver.get uri
    page.should have_content 'Access denied'
  end
end

了解更多关于 webmockVCR。 这还有一个非常不错的关于如何结合他们使用的 视频

探讨这条最佳实践...

Useful formatter

Use a formatter that can give you useful information about the test suite. I personally find fuubar really nice. To make it work add the gem and set fuubar as default formatter in your Guardfile.

good

# Gemfile
group :development, :test do
  gem 'fuubar'

good

# Guardfile
guard 'rspec' do
  # ...
end

good

# .rspec
--drb
--format Fuubar
--color

了解更多关于 fuubar.

探讨这条最佳实践...

编程风格指南

我们正在寻找最佳的“易于阅读”测试的编写风格指南。目前来说 Mongoid test suite 起了一个很好的开头。它编写了简洁而又容易阅读的测试,遵照了这里所说的大部分最佳实践。

帮助完善 Better Specs

这是一个开源的项目。如果有什么遗漏或者错误的地方,请在 GitHub 创建一个 Issue 来讨论这个话题。同时也请查看这些已有的 Issues

  • 多语言 (请创建一个新的 Issue 如果你想翻译这个指南)

帮助我们

如果你觉得这些小提示有用并且对你的工作有所帮助,请考虑进行一个 9 美元的捐助。 所有的捐款都会被用来建设这个站点,让它在写更好的 Ruby 测试的过程中,成为更权威完整的参考。