我注意到像bundler 这样的项目在每个spec file 中都有一个require spec_helper
我还注意到 rspec 采用选项--require，它允许您在引导 rspec 时需要一个文件。您也可以将其添加到 .rspec 文件中，因此每当您运行不带参数的 rspec 时都会添加它。
使用上述方法是否有任何缺点，这可以解释为什么像 bundler 这样的项目选择在每个规范文件中都需要 spec_helper？
【问题讨论】：
我不在 Bundler 上工作，所以我不能直接谈论他们的做法。并非所有项目都签入.rspec 文件。原因是这个文件，通常按照当前的约定，只有一般输出/运行器偏好的个人配置选项。所以如果你只需要 spec_helper 那里，其他人不会加载它，导致测试失败。
另一个原因，不是所有的测试都可能需要spec_helper 执行的设置。最近有一些 Ruby 专家组试图避免在测试中加载过多的依赖项。通过明确说明测试中何时需要spec_helper，人们就会知道可能发生了什么。此外，运行不需要该设置的单个测试文件或目录会更快。
实际上，如果您的所有测试都需要spec_helper，并且您已在项目中明确约定，则没有技术原因您不能或不应该这样做。对于加入该项目的新人来说，这可能是一个最初的惊喜。
【讨论】：
通过适当的设置，完全没有缺点。
.rspec 文件与项目相关（应该像任何其他项目源文件一样提交）。
同时，.rspec-local 用于覆盖个性化设置（它只允许用户覆盖 一些 选项）。
Rails 项目甚至使用单独的 --require rails_helper 用于 Rails 特定的 RSpec 设置。
.rspec 和 --require 选项至少从 2011 年就已经存在（这是很久以前的事了）。
而且，RSpec 尤其是不是供需要辅助轮的人使用的工具 - 您希望人们了解 RSpec 的工作原理以及选项是什么，因为您希望人们知道例如何时何地临时设置--seed 选项，如何更改格式化程序，打开--fail-fast，使用特定标签来处理功能等。
测试环境还必须具有一致的配置，因此您不希望人们调整spec_helper 文件或.rspec 文件（出于相同的原因）。
简而言之：如果它不适用于项目中的每个规范，那么它不应该在spec_helper 文件中。这就是为什么您应该确保它包含在每个规范文件中。而.rspec 文件是最好的方法。
不改用这种方式的唯一原因是当项目被许多人积极维护时（并且任何项目范围内的更改只会造成烦恼，例如强迫人们无缘无故地改变他们的工作与他们的工作有关）。
Bundler 属于这一类 - 适合许多可能同时工作的人。
附：我还建议在空项目上使用rspec --init 并检查生成的配置。
【讨论】：
.rspec 文件（而不是选择的答案）。