一个典型的 RSpec 单元测试广泛使用嵌套的 Ruby 块来构建代码并利用 DSL“魔法”让规范像 BDD 语句一样读取：
describe Foo do
context "with a bar" do
before :each do
subject { Foo.new().add_bar }
end
it "looks like a baz" do
expect # etc
在理想的规范中，每个示例都可以相对简短而精确。然而，外部块似乎通常会增长到 100 行以上，因为 RSpec 结构以这种方式工作，并且不采用很多规范示例，每个示例都可能有几行特定设置，以到达 describe 块与所描述主题的代码大小相同或更大。
Rubocop 最近的升级带来了新规则，即块不应超过 25 行。我不确定它的基本原理，因为它没有在 Ruby style guide 中列出。我明白为什么它可能是一件好事，并添加到默认规则集中。但是，在升级后，我们的 Rubocop 测试多次失败，并显示类似 tests/component_spec.rb:151:3: C: Block has too many lines. [68/25] 的消息
使用 Rubocop 等代码度量工具，我喜欢制定“使用默认值，链接到样式指南，完成工作”的策略。 （主要是因为辩论制表符与空格和其他细节是在浪费时间，而且 IME 永远不会得到解决）这显然是不可能的，我们的两个核心数据质量工具在代码布局方法上存在分歧——或者至少我是这样解释结果的，我认为我们编写规范的方式没有任何本质上的错误。
作为回应，我们简单地将 Rubocop 块大小规则设置为高阈值。但这让我想知道 - 我错过了什么？ RSpec 是否在代码布局中使用了一种现在已经名誉扫地的方法，在我们的 RSpec 测试中我有哪些合理的选择来减少块大小？我可以看到重组代码以避免大块的方法，但它们毫无例外都是丑陋的黑客，纯粹是为了满足 Rubocop 的规则，例如将所有块分解为辅助函数：
def looks_like_a_baz
it "looks like a baz" do
expect # etc
end
end
def bar_context
context "with a bar" do
before :each do
subject { Foo.new().add_bar }
end
looks_like_a_baz
end
end
describe Foo do
bar_context
# etc
. . .我的意思是，这是可行的，但是以这种方式将一堆规范示例转换为辅助函数似乎与 RSpec 设计所鼓励的可读方法相反。
除了想办法忽略它，我还能做些什么吗？
我可以在这里找到的关于这个主题的最接近的现有问题是 RSpec & Rubocop / Ruby Style Guide，这看起来可以通过编辑测试模板来解决。
spec/ 下的 default settings 排除文件。
test/ 的使用让我们接触到了 . . .很高兴知道。这意味着 Rubocop 作者承认 RSpec 代码有些不同，我们也应该如此。
如果一个特定的块通常太长，我指定它而不是文件
Metrics/BlockLength:
IgnoredMethods: ['describe', 'context']
Rubocop 最近的升级带来了新规则，即块不应超过 25 行。我不确定它的基本原理，因为它没有在 Ruby 样式指南中列出。
过去所有的警察都基于 Ruby 风格指南，而 RuboCop 是一种遵守社区规定的做法的方式。
从那时起，方向发生了变化，RuboCop 的范围已经扩大，以帮助开发人员确保其代码库的总体一致性。这导致了两件事：
警察（甚至那些基于 Ruby 风格指南的警察）现在大多是可配置的。对于 Ruby 样式指南中未提及但仍可用于在项目中强制一致性的事情，有一些警察。
这个警察属于第二类。
RSpec 是否在代码布局中使用了一种现在已经名誉扫地的方法，在我们的 RSpec 测试中我有哪些合理的选择来减少块大小？
简短的回答是否定的。 DSL 仍然很酷。 :-)
这个 cop 的目标是命令式编程意义上的大块。作为一般指南，它不适用于通常是声明性的 DSL。例如，在 Rails 中有一个长的 routes.rb 文件是完全良性的。这只是大型应用程序的自然结果，而不是违反样式。 （并且进行大量测试真是太棒了。）
现在，RuboCop 非常聪明，但它不知道什么是 DSL，什么不是，所以我们不能自动忽略它们。有人可能会争辩说，我们可以排除流行框架的 DSL 入口方法，例如 Rails 路由和 RSpec 规范。不这样做的原因主要是：
假阴性。任何类都可以实现一个方法，采用一个块，具有相同的名称。 RuboCop 是一个 Ruby 分析工具，不应该真正了解外部库。 （在我们拥有适当的扩展系统之前，排除 /spec 目录是一种礼貌，这可以由 rubocop-rspec gem 处理。）
我的意思是，这是可行的，但是以这种方式将一堆规范示例转换为辅助函数似乎与 RSpec 设计所鼓励的可读方法相反。
底线是：RuboCop 可以帮助我们编写更好的代码。如果我们的应用程序设计在其他方面是合理的，并且我们发现自己仅仅为了取悦 RuboCop 而使事情变得不那么可读，那么我们应该过滤、配置或禁用 cop。 :-)
作为回应，我们简单地将 Rubocop 块大小规则设置为高阈值。但这让我想知道 - 我错过了什么？
这是一个相当生硬的工具，正如您所暗示的那样，您可能会因此而产生一些误报。这个警察有两种误报：
包含纯声明性 DSL 的文件，例如 Rails 路由、RSpec 规范。将声明性 DSL 混合到大多数命令式代码中的文件，例如 Rails 模型中的 aasm 状态机声明。
在第一种情况下，最好的解决方案是排除文件或目录，在第二种情况下使用内联禁用。
在您的情况下，您应该使用以下内容更新您的 .rubocop.yml：
Metrics/BlockLength:
Exclude:
- 'Rakefile'
- '**/*.rake'
- 'test/**/*.rb'
（请注意，您需要从默认配置中重新迭代基本排除项，因为该列表将被覆盖。）
关注公众号
不定期副业成功案例分享
ExcludedMethods已重命名为IgnoredMethods