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
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
...
小结: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
两个expect都会运行。并在命令行窗口输出错误❌。
我们真正聚合的是可能失败的期望,而不是一般性失败。尽管如此,我还是喜欢聚合失败这
个功能,而且经常在测试中使用。
aggregate_failure do..end
8.6 维护测试的可读性
如果测试十分臃肿,可以使用:
单层抽象测试法:
把每一步提取出来,定义为单独的辅助方法,这样在阅读测试时,我们就不用来回变换上下 文。如果以后要添加新期望,也定义为辅助方法,而不直接写在测试用例中。
作者只建议老手这么做(熟练掌握RSpec和Capybara)。因为辅助方法多了可读性也会下降。