Rspec: everyday-rspec实操: 第8章DRY. （6个方法，其中3个方法好上手）

Don't Repeat Yourself.

• 把操作步骤提取到辅助模块中;✅
• 通过let复用测试中的实例变量;✅
• 把通用的设置移到共享的情景中;⚠️（不喜欢）
• 在RSpec和rspec-rails提供的匹配器之外，自定义匹配器;⚠️未学习

• 把多个测试用例中的期望合到一个测试用例中;✅aggregate_failure do ..end
• 判断何时可以抽象，何时应该写在测试中。 ❌，老手才会这么做。

8.1 support module

拉下来的分支不知道什么原因又错误。自己在第6章features test又开了一个分支06-text

另外不知道什么原因不能登陆devise. 在从开的06-text可以正常使用。

本节讲的是把登陆代码提取出来建立一个模块，用的时候引用就行了。把模块建立在support文件夹下面。如support/login_support.rb，然后RSpec引入模块，或者手动include需要的地方。

或者使用Devise自带的方法，引用模块Warden::Test::Helpers,不过这个不包含进入首页，所以还要visit root_path

login_as user, scope: :user

visit root_path

8.2 let 实现惰性加载。

在同一个块内,describe, context, before的作用是在example之前加载好数据。

let()方法是在it内调用它声明的变量时，才会加载预构件或固件。

所以：before中的变量用的是实例变量@variable, 而let定义的是变量只在当前块内新建，使用，然后销毁。

React中的let相当于变量可以修改,对应的是const 不可修改。

举例：模型测试task, 建立测试模型和预构件。

rails generate rspec:model task

create spec/models/task_spec.rb

invoke factory_girl

create spec/factories/tasks.rb

RSpec.describe Note, type: :model do

let(:user){FactoryGirl.create(:user)} #这里声明了预构件变量

let(:project){FactoryGirl.create(:project, owner: user)}

it "is valid with a user, project, and message" do

note = Note.new(

message: "This is a sample note.",

user: user, #这里加载了let(:user)

project: project, #这里加载了let（:project）

)

expect(note).to be_valid

end #block结束后删除变量user, project

...

小结：let还有变形 let! ：加载预构件，不是惰性加载了，避免使用let!

可以考虑before块和实例变量，设置直接在需要测试的example中定义测试数据也行。

根据团队需要灵活使用。

8.3 shared context

共享情景，在不同文件中共享let定义的预构件。

我不觉得太好。因为有点过度重构了，不利于他人的维护。本身使用预构件就已经简化了。

let 能让测试数据在多个测试用例中共用，而共享的情景能让相同的设置在多个测试文件中共用。

support／contexts/XXX_setup.rb

RSpec.shared_context "XXX setup" do

#let()... 写let

end

在其他测试中include_context "XXX setup"

8.4 self-define matcher (未看)自定义匹配器

8.5 聚合失败 aggregate failure

Rspec3.3新功能。

约定俗称，在model test and controller test中每个example只放一个expect(), 因此用不到aggregate failure功能。

而在, feature test and request test中每个example可以放多个expect(), 如果前一个expect出错,则停止运行后面的expect测试。

因此需要用到aggregate failure功能让后面的expect()继续测试。

如： spec/controllers/projects_controller_spec.rb

it "responds successfully" do

# sign_in @user #注释掉

get :index

aggregate_failures do

expect(response).to be_success

expect(response).to have_http_status "200"

end

两个expect都会运行。并在命令行窗口输出错误❌。

我们真正聚合的是可能失败的期望，而不是一般性失败。尽管如此，我还是喜欢聚合失败这
个功能，而且经常在测试中使用。

aggregate_failure do..end

8.6 维护测试的可读性

如果测试十分臃肿，可以使用：

单层抽象测试法:

把每一步提取出来，定义为单独的辅助方法，这样在阅读测试时，我们就不用来回变换上下文。如果以后要添加新期望，也定义为辅助方法，而不直接写在测试用例中。

作者只建议老手这么做(熟练掌握RSpec和Capybara)。因为辅助方法多了可读性也会下降。