我最近在“spec / features”中构建了一个功能规范,在功能规范的中间,我决定尝试这样做
context "foo", type: :request do
it "works" do
get some_path
expect(response.body).to eq("something")
visit some_path
expect(page).to have_content("something")
end
end
令我惊讶的是,它确实奏效了。通常在功能规范中,您无法对get
,post
等方法进行调整,并且在请求规范中,您无法调用capybara visit
方法。它也是另一种方式。如果我在“spec / requests”中的请求规范中,我可以用以下内容标记:feature并获得相同的行为。
这是否支持rspec行为?我知道这可能存在设计/概念上的问题,但这两者是否存在技术上的不利因素?
答案 0 :(得分:1)
this blog post概述了我们现在所知的功能规格和请求规范被拆分为单独目录的原因。
总之,尽管如此,在Capybara 2.0中完成拆分它们是为了减轻混淆单一类型的规范,request
规范,负责执行全栈集成测试以及高级规范,仅使用其外部接口驱动应用程序(通常通过无头Web浏览器完成)。因此,目前普遍认同的规范结构将是:
visit
等)的任何内容置于page
spec/features
对象上进行断言
get
等)的全栈非控制器规范置于response
spec/requests
对象上的断言
如果可以的话,最好不要将两者混合在一起,即使它是可能的,如果没有其他原因,只要遵守惯例并给你未来的同事减少意外。
至于为什么你可以根据需要混合规范,它主要与RSpec配置有关,所以它是受支持的行为:
config.infer_spec_type_from_file_location!
某处可能会有rails_helper.rb
行,这意味着RSpec会将spec/features
中的所有文件视为要素规范以及spec/requests
中的所有文件要求规格type: :request
文件夹中的规范周围打包spec/features
标志,因此只允许对Rack DSL进行单一规范访问,它仍然访问Capybara DSL 你甚至可以使用RSpec.config
允许Capybara DSL进入你想要的任何规范类型或目录路径,尽管这是not recommended:
RSpec.configure do |config|
config.include Capybara::DSL, type: :request
config.include Capybara::DSL, file_path: %r{spec/requests}
end
总的来说,为了您的代码库,未来的您和您未来的同事,最好尽量将所有内容放在正确的位置。