apexy (apexy)

深入 Rails 的 Zeitwerk 模式

apexy — Thu, 08 Dec 2022 11:44:30 +0800

原文请参看我的博客：

https://xfyuan.github.io/2022/12/deep-into-rails-zeitwerk-autoloader/

=======================================================================

本文已获得原作者（Simon Coffey）授权许可进行翻译。原文深入讲述了 Rails 中新的 Zeitwerk 自动加载模式的实现原理，是对前一篇《Rails7 的 Zeitwerk 模式解惑》很好的补充

原文链接：Rails autoloading — now it works, and how!
作者：Simon Coffey（Twitter）

【正文如下】

Rails 从一开始就有自动加载。自动加载意味着当我们想要引用User model 时，不必还要手写require 'User'。没人有时间为每个需要用到User的文件都来这么干，对吧？

我已经写过一篇关于 Rails 最早的 autoloader（现在叫做“传统”模式的 autoloader）的文章【译者注：该文链接】：它是如何工作的，又是如何创造了诸多弊端的。那个时候，我对它很是气愤，为它可浪费了不少时间来调试它造成的问题。

前一篇文章涵盖了很多细节，但传统的自动加载的诸多问题的根本在于其机制：它使用了Module#const_missing来检测一个常量何时无法通过正常含义来解析，然后它尝试去查找并加载一个文件来定义它。

有两个原因使得这种方案无法很可靠地工作：

Module#const_missing仅当一个常量无法通过正常含义来解析时才执行。因为 Ruby 中给定的常数引用可以潜在地解析为许多常数定义，这意味着在某些情况下，Ruby 可以在自动加载生效之前就为一个常量引用返回了错误的值。
当Module#const_missing被执行时，它并未提供足够的信息来可靠地检测是哪个常量应该被返回。这也就意味着，自动加载，有时将会为一个常量引用返回错误的值得。

经典的 autoloader 的大部分复杂性都涉及修补这两个无法克服的问题，这使得其很难理解或调试，也不可避免地会出错。

然而对 Rails 6，有了一个新的 loader：Zeitwerk。它声称已经解决了传统模式的所有问题，这真是个令人兴奋的消息！

为了做到这点，它使用了三个关键机制：

Module#autoload
Kernel#require
TracePoint

让我们来看看他如何把这些编织到一起的。

Goodbye `#const_missing`, Hello `#autoload`

Ruby 有一个内置的自动加载机制，Module#autoload。这使我们可以提前告诉 Ruby 哪个文件将定义一个特定的常量，而无需付出立即加载该文件的成本。仅当我们第一次引用到那个常量时，Ruby 才会实际去加载它：

# a.rb
puts "Loading a.rb"
A = "Hi! I'm ::A"

autoload :A, 'a'

puts A
# Loading a.rb
# Hi! I'm ::A

而这跟Module#const_missing的最重要差别在于，我们告诉 Ruby 哪个文件定义了哪个常量，在该常量被使用之前，且在常量解析期间这个信息会被带入进去。

这就潜在地排除了#const_missing方案上述两个关键性的错误。我们将不再试图去检测并从错误中恢复，而只是用额外的信息来增强 Ruby 现有的常量解析机制。

要使用Module#autoload，你需要在常量被使用之前就知道哪个文件将定义给定的常量。Rails（以及 Ruby 约定）在常量名称和文件之间定义了可预测的映射，这在理论上让我们能够自动化如下变换：

MyModule::MyClass # => my_module/my_class.rb

然而，传统的 autoloader 支持在初始化时从不存在的文件中来加载常量。如果我在app/models/user.rb中创建了一个新的User model，我可以直接在一个已经打开运行中的 rails console 里调用User.create而无需做任何事情。

除非有某些进程监控着文件系统的改变，否则我们是无法使用Module#autoload在其初始化时来自动加载不存在的文件的。监控文件系统很麻烦，也不那么可靠，特别是你需要支持多个操作系统时。

不过，这个功能会多有用呢？如果我们缩减 autoloader 的定义域，让其初始化时仅仅支持已存在的文件的话，Module#autoload便成为了一个选择。事实上，这就是 Zeitwerk 所做的事。我们通过实例来看看。

Loading a single file

要使用 Zeitwerk，我们初始化一个 loader，并给它一个或多个根目录以从中加载。通过加入一个 logger，就能看到它的操作：

loader = Zeitwerk::Loader.new
loader.push_dir('/ex')
loader.logger = Logger.new(STDOUT)

现在我们就可以把一些文件放入根目录中，启动 loader。在贯穿本文的示例代码片段中，我会在那些影响结果的行之后以注释形式展示打印的输出。

# /ex/a.rb
A = "Hi! I'm ::A"

loader.setup
# Zeitwerk: autoload set for A, to be loaded from /ex/a.rb

puts A
# Zeitwerk: constant A loaded from file /ex/a.rb
# Hi! I'm ::A

当我们调用loader.setup时能看到 Zeitwerk 检测并准备要自动加载的文件（这正是Module#autoload执行的时候）。然后当我们第一次引用常量A时，就看到它从之前被检测到的文件中被载入，最终我们看到了其打印出的值。

有趣的是，Zeitwerk 可以检测实际发生的加载以记录下它！要看到它是如何做的，让我们来看看比单个文件更复杂的情况。

Implicit namespaces

在第一个示例中，我们看到了单个文件在 loader 的根路径内。几乎任何有一定体积的项目都会有一定深度的目录结构，以及一定深度的嵌套模块。

如果我们创建一个文件c/d.rb，则会想要加载一个常量C::D。这意味着我们必须首先加载C。

然而，C可能会是一个无趣的命名空间模块；如果对每个这样的命名空间我们都不得不为其创建如下的样板文件，那就很乏味了：

# /ex/c.rb
module C
end

因此 Zertwerk 允许这些命名空间是隐式的。无需那些样板文件，Zeitwerk 从目录名来“自动导入”命名空间模块；本质上，它不需要那样一个 ruby 文件就为我们声明了一个名为C的模块。

不过，这展示了一个问题：我们使用 ruby 默认的Module#autoload来做实际的加载，而它对所要转换为模块的目录一无所知。那么，我们如何告诉 ruby 要怎样提前加载C呢？

来看看当目录中只有单个文件时会发生什么：

# /ex/c/d.rb
C::D = "Hi! I'm C::D"

loader.setup
# Zeitwerk: autoload set for C, to be autovivified from /ex/c

在初始化的 setup 时，我们可以看到 Zeitwerk 只为自动加载准备了C。因此，它一定只立刻查找根目录的文件。

在根目录里，它只发现了一个目录，/ex/c，所以它不会说从一个文件“C...被自动加载”，而是会说从那个目录“C...被自动导入”了。

puts C
# Zeitwerk: module C autovivified from directory /ex/c
# Zeitwerk: autoload set for C::D, to be loaded from /ex/c/d.rb
# C

然后当我们引用C时，会看到它被自动导入了，然后C::D被为自动加载而得到设置——Zeitwerk 必须向下深入c目录以查找更多要自动加载的东西。

puts C::D
# Zeitwerk: constant C::D loaded from file /ex/c/d.rb
# Hi! I'm C::D

最终我们引用到了C::D，它从c/d.rb这个常规的 ruby 文件得以被自动加载。

如果没有 ruby 文件被读取，关于C 的自动导入又是如何工作的呢？

Zeitwerk 通过拦截Module#autoload其中的加载那一部分代码来做到这点。当我们调用autoload :C, '/ex/c'时，这意味着在C被首次使用的时候，ruby 会自动调用require '/ex/c'。

默认情况下，如果我们试图require一个目录时，ruby 会抛出一个LoadError。但由于Kernel#require是跟 ruby 任何其他方法一样的方法，Zeitwerk 就能够拦截该require调用，在其中加入一些“猴子补丁”：

# lib/zeitwerk/kernel.rb
module Kernel
  module_function

  alias_method :zeitwerk_original_require, :require

  def require(path)
    if loader = Zeitwerk::Registry.loader_for(path)
      if path.end_with?(".rb")
        zeitwerk_original_require(path).tap do |required|
          loader.on_file_autoloaded(path) if required
        end
      else
        loader.on_dir_autoloaded(path)
      end
    else
      # code to handle paths not managed by Zeitwerk
    end
  end
end

现在 Zeitwerk 就有机会在文件被读取之前去查找所要加载的路径了。通过使用绝对文件路径和.rb扩展名（这是可选的）来声明其自动加载，它就能可靠地知道哪个require的调用是在其所负责的目录内，以及哪些是针对目录或 ruby 文件的。

对于应用中每个加载的文件，Zeitwerk 都做了如下一些事：

如果它是一个由 loader 负责管理的 ruby 文件……
- 就让 ruby 加载它，并标记其常量为已加载
如果它是一个由 loader 负责管理的目录……
- 就自动导入模块，并设置其子目录用于自动加载
否则，loader 就不做管理，则……
- 让 ruby 加载它吧

目录处理的代码相当难懂，但这里我们能够看到命名空间模块被创建，被赋予给有关的常量名，然后加载操作记录下日志。

到此为止，一切良好！我们加载了常规的文件，看到了隐式命名空间，已有的目录被用于推断命名空间模块。这已经涵盖了 Zeitwerk 三个主要基石技巧中的两个了。

要看到 Zeitwerk 的行囊中最后那一个杀手锏，得来看看另一个场景。

Explicit namespaces

有时候我们确实想要显式定义命名空间模块，比如在那个模块上有一个方法时。这个场景下将会同时需要一个 ruby 文件来定义模块，和包含那些文件的目录来定义命名空间常量。

这意味着当我们加载一个常规 ruby 文件时，有额外的工作要做。如果那个文件定义了一个 class 或一个 module，并且有一个匹配的子目录在其加载路径中，我们就需要确保为那个子目录设置了自动加载，就如同上面为隐式命名空间所做的那样。

这就是TracePoint 的用武之地了。TracePoint是 ruby 标准库的一部分，能让我们为发生在 ruby 解释器中的确定事件来定义回调，这些事件有：方法调用，module 或 class 的定义，等等。

我们对:class事件特别感兴趣，该事件会在一个 module 或 class 无论何时被定义时都告知我们：

trace = TracePoint.new(:class) do |tp|
  puts [tp.event, tp.self].inspect
end
trace.enable

module A; end
# [:class, A]

通过在这个事件上设置一个 trace，Zeitwerk 就能在任何新模块被定义时知道。类似于它查看require的调用以检查它是否负责这些路径，它去查看 class 或 module 的名称以查看它是否是一个常量，其加载应该由 Zeitwerk 来负责。

来看看 Zeitwerk 的做法：

# /ex/c.rb
module C
  def self.hello
    "Hi! I'm ::C"
  end
end

# /ex/c/d.rb
module C
  D = "Hi! I'm C::D"
end

loader.setup
# Zeitwerk: autoload set for C, to be loaded from /ex/c.rb

puts C.hello
# Zeitwerk: autoload set for C::D, to be loaded from /ex/c/d.rb
# Zeitwerk: constant C loaded from file /ex/c.rb
# Hi! I'm ::C

puts C::D
# Zeitwerk: constant C::D loaded from file /ex/c/d.rb
# Hi! I'm C::D

这里我们能看到 Zeitwerk 在c.rb还仍然在加载时就能够检测C的定义。由于C是一个它所负责的常量，并且由于有一个c目录在 loader 的根目录内，它就向下深入到c目录里并设置那个位置的自动加载，搜寻d.rb，并设置C::D的自动加载。

事实上，这比它表现出来的还要灵活。我们能够从任何地方重新打开自动加载的常量，即使定位已经在 Zeitwerk 所管理路径之外，并且 loader 路径内的定义将依旧能生效。

使用同样的文件来作为我们最后一个示例：

loader.setup
# Zeitwerk: autoload set for C, to be loaded from /ex/c.rb

module C
  # Zeitwerk: autoload set for C::D, to be loaded from /ex/c/d.rb
  # Zeitwerk: constant C loaded from file /ex/c.rb
  puts D
  # Zeitwerk: constant C::D loaded from file /ex/c/d.rb
  # Hi! I'm C::D
end

puts C.hello
# Hi! I'm ::C

这是一个在传统自动加载模式下会失败的例子。当我们打开在加载路径之外的C模块，且它还未被加载时，我们就定义了它；而Module#const_missing根本就没被调用。因此，c.rb将永远不会被加载，而方法C.hello将永远不会被定义。

然而，使用 TracePoint，我们就能发现 autoloader 所应负责的常量的重定义，并从 loader 路径（如果存在的话）预先加载相关文件。

Conclusion

对于 Zeitwerk 还有更多内容（预加载，重加载，线程安全，等等），但那已经超出本文篇幅了。

至此真是令人愉悦的旅程。这儿仍然有复杂的地方，但基石看起来确实非常牢固了。我还没有在新项目上使用新的 loader，但当我这样做时，我觉得会更有信心，可以或多或少地使用常量（特别是命名空间模块），而不必再太花心思了。

非常感谢 Xavier Noria 以及其他所有为 Zeitwerk 做出贡献的人！

Rails7 的 Zeitwerk 模式解惑

apexy — Thu, 08 Dec 2022 11:42:44 +0800

原文请参看我的博客：https://xfyuan.github.io/2022/11/rails7-zeitwerk-mode/

=================================================================

本文已获得原作者（Athira Kadampatta、Supriya Laxman Medankar）和 Kiprosh 授权许可进行翻译。原文详细讲述了 Rails 7 中新的 Zeitwerk 自动加载模式。

原文链接：Autoloading pitfalls fixed by Rails 7’s default Zeitwerk mode
作者：Athira Kadampatta、Supriya Laxman Medankar
站点：Kiprosh，一家印度的软件开发公司。

【正文如下】

Rails 中传统的 autoloader 很有帮助，但仍然有一些瑕疵造成自动加载偶尔会出毛病。为了解决这个问题， Xavier Noria 在 Rails 6 的这个 PR 中提出了 zeitwerk 模式并使其可配置使用。Rails 7 则更进一步，zeitwerk 完全替代了传统的 autoloader。

本文中，我们会看看传统的自动加载会碰到的问题，以及 Zeitwerk 模式如何解决的。（你可以阅读这篇文章来理解 Rails 的 autoloader 是怎样工作的）。

How classic autoloading works?

起初，Rails 使用的是在 Active Support 中称作 Classic Autoloading 的实现来作为 autoloader，一直持续到 Rails 6。

Classic Autoloading 依赖的是 Ruby 的常量查找。要解析一个常量，会首先在所定义的类的词法域中查找，然后在其祖先链中查找。如果该常量未找到，const_missing方法就会被 Ruby 调用。Rails 覆写了 Ruby 的const_missing 方法，并使用autoload_paths 根据惯例约定来解析常量。

How zeitwerk autoloading works?

新引入的 Zeitwerk Mode 则不依赖 Ruby 的常量查找。

相反，它利用的是 Ruby 的 Module#autoload 方法提前告知 Ruby 哪个文件将定义一个特定常量，而不需要立即加载该文件。

Common Problems resolved by zeitwerk mode

传统模式存在许多问题，但都已被 zeitwerk 模式解决了。这其中，我们会看看三个不同的陷阱，每个都带有示例。

1、When Constants aren't Missed

假设我们有如下 model 结构：

# course.rb
class Course
  def initialize
    puts "From Course"
  end
end

# mit_university/course.rb
module MitUniversity
  class Course
    def initialize
      puts "From MitUniversity::Course"
    end
  end
end

# mit_university/engineering.rb
module MitUniversity
  class Engineering
    def initialize
      @course = Course.new
    end
  end
end

With Classic Mode

Loading development environment (Rails 5.2.7.1)
2.7.5 :001 > Course.new
From Course
 => #<Course:0x0000563bfa029810>
2.7.5 :002 > MitUniversity::Engineering.new
From Course
 => #<MitUniversity::Engineering:0x0000563bf9e7ab40 @course=#<Course:0x0000563bf9e7aaf0>>

这里，由于我们在调用MitUniversity::Course之前调用了Course，Ruby 的常量查找就已经在内存中自动加载了Course，所以如果我们想要为MitUniversity::Engineering创建一个对象时，它就会引用到已在内存中被自动加载的Course，而不去搜索MitUniversity::Course了。这让自动加载依赖于常量被调用的顺序。

With Zeitwerk Mode

Loading development environment (Rails 7.0.3)
2.7.5 :001 > Course.new
From Course
 => #<Course:0x00005615a9707fa0>
2.7.5 :002 > MitUniversity::Engineering.new
From MitUniversity::Course
 => #<MitUniversity::Engineering:0x00005615ae41d290 @course=#<MitUniversity::Course:0x00005615ae40b270>>
2.7.5 :003 >

因为 zeitwerk 模式为所有常量定义了autoload_path，它已经知道了到哪里去查找哪个常量。所以尽管首先初始化Course，但在MitUniversity::Engineering类中调用时，它仍然如期望的那样加载了MitUniversity::Course。

2、Autoloading within Singleton Classes

这是一个关于 Singleton 类方法的类似问题，已经被 zeitwerk 模式所解决。例子如下所示：

# mit_university/course.rb
module MitUniversity
  class Course
    def initialize
      puts "From MitUniversity::Course"
    end
  end
end

# mit_university/engineering.rb
module MitUniversity
  class Engineering
    class << self
      def details
        Course.new
      end
    end
  end
end

With classic mode

如果我们在调用MitUniversity::Course之前调用 MitUniversity::Engineering.details，它将会抛出uninitialized constant Course的错误。这是由于，当自动加载被触发时，Rails 只去检查顶层命名空间，因为 singleton 类是匿名的，所以 Rails 不会知道嵌套的MitUniversity。

Loading development environment (Rails 5.2.7.1)
2.7.5 :001 > MitUniversity::Engineering.details
Traceback (most recent call last):
        2: from (irb):3
        1: from app/models/mit_university/engineering.rb:5:in `details'
NameError (uninitialized constant Course)
2.7.5 :002 > MitUniversity::Course
 => MitUniversity::Course
2.7.5 :003 > MitUniversity::Engineering.details
From MitUniversity::Course
 => #<MitUniversity::Course:0x0000560cabb27c18>

With zeitwerk mode

Zeitwerk 模式则不会抛出任何错误，并且即使之前没有自动加载它也能载入该常量。

Loading development environment (Rails 7.0.3)
2.7.5 :001 > MitUniversity::Engineering.details
From MitUniversity::Course
 => #<MitUniversity::Course:0x0000559ebba13dd0>

3、Autoloading and Single-table Inheritance (STI)

假设我们有如下 Single-table Inheritance (STI) 的 model 已定义：

class Polygon < ApplicationRecord
end

class Triangle < Polygon
end

class Rectangle < Polygon
end

class Square < Rectangle
end

Square继承自 Rectangle，所以当我们调用Rectangle.all时，结果必须包含Polygon类型的Square以及Rectangle。

With classic mode

然而，当我们调用Rectangle.all时，并不能在结果中看到Square记录。我们可以看到所生成的 SQL 查询中并未包含Square。

Loading development environment (Rails 5.2.7.1)
 2.7.5 :001 > Rectangle.all
  Rectangle Load (0.4ms)  SELECT `polygons`.* FROM `polygons` WHERE `polygons`.`type` = 'Rectangle' /* loading for inspect */ LIMIT 11
 => #<ActiveRecord::Relation [#<Rectangle id: 1, area: 100.0, type: "Rectangle", type_id: nil, created_at: "2022-08-28 14:00:50.705523000 +0000", updated_at: "2022-08-28 14:00:50.705523000 +0000">, #<Rectangle id: 2, area: 200.0, type: "Rectangle", type_id: nil, created_at: "2022-08-28 14:01:09.543825000 +0000", updated_at: "2022-08-28 14:01:09.543825000 +0000">]>
 2.7.5 :002 > Square
 => Square(id: integer, area: float, type: string, type_id: integer, created_at: datetime, updated_at: datetime)
 2.7.5 :003 > Rectangle.all
  Rectangle Load (0.9ms)  SELECT `polygons`.* FROM `polygons` WHERE `polygons`.`type` IN ('Rectangle', 'Square') /* loading for inspect */ LIMIT 11
 => #<ActiveRecord::Relation [#<Rectangle id: 1, area: 100.0, type: "Rectangle", type_id: nil, created_at: "2022-08-28 14:00:50.705523000 +0000", updated_at: "2022-08-28 14:00:50.705523000 +0000">, #<Rectangle id: 2, area: 200.0, type: "Rectangle", type_id: nil, created_at: "2022-08-28 14:01:09.543825000 +0000", updated_at: "2022-08-28 14:01:09.543825000 +0000">, #<Square id: 5, area: 250.0, type: "Square", type_id: nil, created_at: "2022-08-28 14:01:52.165141000 +0000", updated_at: "2022-08-28 14:01:52.165141000 +0000">]>

要解决这个问题，我们不得不在rectangle.rb文件底部加上require_dependency 'square'：

# app/models/rectangle.rb
class Rectangle < Polygon
end
require_dependency 'square'

With zeitwerk mode

由于在 zeitwerk 模式中，Square已被自动加载进来，我们就无需添加require_dependency 'square'这一行了：

Loading development environment (Rails 7.0.3)
2.7.5 :001 > Rectangle.all
  Rectangle Load (0.9ms)  SELECT `polygons`.* FROM `polygons` WHERE `polygons`.`type` IN ('Rectangle', 'Square') /* loading for inspect */ LIMIT 11
 => #<ActiveRecord::Relation [#<Rectangle id: 1, area: 100.0, type: "Rectangle", type_id: nil, created_at: "2022-08-28 14:00:50.705523000 +0000", updated_at: "2022-08-28 14:00:50.705523000 +0000">, #<Rectangle id: 2, area: 200.0, type: "Rectangle", type_id: nil, created_at: "2022-08-28 14:01:09.543825000 +0000", updated_at: "2022-08-28 14:01:09.543825000 +0000">, #<Square id: 5, area: 250.0, type: "Square", type_id: nil, created_at: "2022-08-28 14:01:52.165141000 +0000", updated_at: "2022-08-28 14:01:52.165141000 +0000">]>

Conclusion

对于 Rails 7，Zeitwerk 已经成为默认模式，而传统模式已不可用了。这是一个很有影响的变化，改进了 Rails 中常量自动加载的方式，解决了诸多如上所述的传统模式带来的问题。

References

Rails 6.1 正式发布了～！

apexy — Thu, 10 Dec 2020 09:57:06 +0800

新特性：

Horizontal Sharding,
Multi-DB Improvements,
Strict Loading,
Destroy Associations in Background,
Error Objects,
and more!

https://weblog.rubyonrails.org/2020/12/9/Rails-6-1-0-release/

TestProf 文档中文版上线（和跟作者 Vladimir 交流的过程及感受）

apexy — Tue, 18 Aug 2020 14:31:22 +0800

这是对 TestProf 中文文档翻译经过的一个简要记录，以及跟作者 Vladimir 交流的过程及感受。（本文在我的博客地址：https://xfyuan.github.io/2020/08/testprof-chinese-doc-is-online/）

我在自己的前几篇博客中翻译推荐了关于 TestProf 的一些使用方法和技巧，这个 Evil Martins 出品的 Ruby 测试工具 Gem 的强大和有趣，从中可窥一斑。要想了解和使用 TestProf 的全部功能，当然还是需要去看它的官方文档（地址：https://test-prof.evilmartians.io）。顺便说一句，连这个 Gem 文档的网站都秉承了 Evil Martins 的一贯风格，同样的精致，同样的讲究设计感。

为了更好地推荐给国内的 Ruby 开发者，于是我有了一个大胆的想法。我给 TestProf 作者 Vladimir Dementyev 发了邮件，向他询问关于把 TestProf 的文档进行中文化的意向。Vladimir 技术很厉害，没想到人也非常好沟通。作为作者，他当然也是希望把文档翻译成更多的本地化语言，好推广给更多的 Ruby 开发者了。不过他同时回复说文档网站目前还不支持多语言，需要先调研一下，尽快告诉我结果。

而他只用了两个晚上，就搞定了把原本只支持英文的文档网站，扩展升级为支持多语言的版本，并且添加了全部文档的俄语版本进行验证。既然文档的网站一切准备就绪，那么接下来就等我的中文化翻译了。

翻译工作从 2020.07.24 开始，到 2020.08.12 完成最后一篇，共耗时 12 天。

中文版本来可以那时就上线的，不巧的是，正好碰上是 Vladimir 的假期，只能等他回来再处理。

今天，TestProf 文档的中文版终于正式放出，可供所有 Ruby 开发者查阅了。效果如下：

Vladimir 也在 Twitter 上发布了中文版文档上线的消息:)

衷心希望 TestProf 的中文文档能够帮助所有国内的 Ruby 开发者把测试写得更加高效，也让编写测试成为一种乐趣，从而让 Ruby/Rails 程序更加完美！

TestProf II —— Ruby 测试的 “工厂疗法”（翻译）

apexy — Sat, 25 Jul 2020 11:17:31 +0800

本文已获得原作者（Vladimir Dementyev）和 Evil Martians 授权许可进行翻译。原文是 TestProf 这个 Evil Martians 出品的 Gem 介绍文章系列的第二篇。作者介绍了造成 Ruby 慢测试的一个主要元凶——Factory Cascade，以及如何使用 TestProf 来消灭这个元凶。文中也提到了众所周知的 Factories vs. Fixtures 问题，而 TestProf 可以做到让你鱼和熊掌兼得。

我的翻译 Blog 链接在这里：https://xfyuan.github.io/2020/07/testprof-factory-therapy-for-ruby-tests/

原文链接：TestProf II: Factory therapy for your Ruby tests — Martian Chronicles, Evil Martians’ team blog
作者：Vladimir Dementyev
站点：Evil Martians ——位于纽约和俄罗斯的 Ruby on Rails 开发人员博客。它发布了许多优秀的文章，并且是不少 gem 的赞助商。

【下面是正文】

概述

学习如何把你的 Ruby 测试套件带回到健康满满、速度满满的路上，通过使用 TestProf——一个强大的工具包来诊断所有跟测试有关的问题。这一次，我们来聊聊 factories：它们如何拖慢你的测试，如何来估量那些负面影响，如何避免，以及如何让你的 factories 跟 fixtures 一样快。

前言

TestProf，用于很多 Evil Martians 的项目，以缩短 TDD 的反馈环，对任何其测试运行时间超过一分钟的 Rails（或其他基于 Ruby 的）应用而言都是一个必备工具。它通过扩展有关功能而对 RSpec 和 minitest 均可适用。

在我们展示该开源项目的介绍文章里，当时承诺会有一篇专门文章来讲述在测试 Ruby Web 应用时被经常忽视的一个问题：factory cascades。本文就是我们所承诺的东西。

通过在你的实际测试中运行一下 TestProf 有个概览是比较好的。所以如果你手边恰好有一个 RSpec 覆盖的 Rails 项目，且使用了 factory_bot（之前闻名的名字叫 factory_girl）的 factories——我们建议你阅读下去之前安装该 gem，那么这将会是一个互动式演练！

安装 TestProf 很简单，把下面这行添加到你Gemfile的:test组：

group :test do
  gem 'test-prof'
end

Crumbling factories

无论何时要测试自己的应用时，我们都需要生成测试数据——两种常见的方式就是 factories 和 fixtures。

factory 是一个可以根据预定义 schema 生成其他对象（可以被持久化，也可以不）并动态实现的对象。

Fixtures 相当于一个不同的方案：它们声明数据的静态状态，其会被立即加载到测试数据库中，且通常在测试运行之间保持不变。

在 Rails 世界中，我们有内置 fixtures 和广受欢迎的第三方 factory 工具（比如 factory_bot, Fabrication, 及其他）。

尽管关于 “factories vs. fixtures” 的辩论看起来永远不会停止，不过我们仍然把 factories 视为一种更加灵活也更易于维护的方式来处理测试数据。

然而，能力越大责任越大：factories 更容易让你搬起石头砸自己的脚，让你的测试陷入困境。

那么，我们如何判断自己是否滥用了这种能力并且该怎么办？首先，让我们来看看测试套件耗费在 factories 上的时间有多少。

对此，我们应该使用这个“良医”：TestProf。该 gem 是个完整的诊断工具包，EventProf 为其中工具之一。顾名思义：它是一个事件分析器，可以让它追踪factory.create事件，它会在你每次调用FactoryBot.create()时被触发，同时一个 factory 生成的对象被保存到数据库中。

EventProf 对 RSpec 和 minitest 都支持，有一个命令行界面，所以在任何 Rails 项目目录下启动终端（当然，它必须得有测试和 factories，且本文中所有测试用例都假设用的是 RSpec）并运行如下命令：

$ EVENT_PROF="factory.create" bundle exec rspec

在输出中，你可以看到从 factories 创建数据所花费的总时间，以及前五个最慢的测试：

[TEST PROF INFO] EventProf results for factory.create

Total time: 03:07.353
Total events: 7459

Top 5 slowest suites (by time):

UsersController (users_controller_spec.rb:3) – 00:10.119 (581 / 248)
DocumentsController (documents_controller_spec.rb:3) – 00:07.494 (71 / 24)
RolesController (roles_controller_spec.rb:3) – 00:04.972 (181 / 76)

Finished in 6 minutes 36 seconds (files took 32.79 seconds to load)
3158 examples, 0 failures, 7 pending

从我们项目之一取出的一个真实范例中（重构之前），在六分半的测试运行时间里，超过三分钟是用于生成测试数据，其几乎占据了 50%。这并不令人惊讶：我曾经工作过的一些代码库上，从 factories 生成数据花费了多达 80% 的测试时间。

平静一下，请继续阅读，我们明白如何修复这个问题。

The name of the game is “cascade”

根据多年以来的观测和对 TestProf 的开发，以及对所有与测试有关东西的分析，慢测试的原因里最大的一个是——factory cascade。

让我们来做一个演示：

factory :comment do
  sequence(:body) { |n| "Awesome comment ##{n}" }
  author
  answer
end

factory :answer do
  sequence(:body) { |n| "Awesome answer ##{n}" }
  author
  question
end

factory :question do
  sequence(:title) { |n| "Awesome question ##{n}" }
  author
  account # suppose it's our tenant in SaaS application
end

factory :author do
  sequence(:name) { |n| "Awesome author ##{n}" }
  account
end

factory :account do
  sequence(:name) { |n| "Awesome account ##{n}" }
end

现在，试着猜一下，一旦你调用create(:comment)，会有多少条记录被创建到数据库中？如果你已经有了答案，请继续往下看。

首先，我们对于comment生成了一个body。但还没有记录被创建，所以这时总数是 0。
接下来，对于comment我们需要一个author。author应该属于account，因此我们创建了两条记录。总数：2。
每个 comment 需要一个可注释的对象，对吧？我们这里是answer。answer自身需要一个author跟account。这就多了三条记录。总数：2 + 2 = 4。【译者注：原文这里有点描述不清晰。前面说“三条记录”，是把 answer、author、account 一起算上的，后面总数计算的数字又按 2 来加，应该没计入 answer。结合后文看，answer 是在最后一步才计入的，所以这里按 2 算是对的。】
answer也需要一个question，其有自己的author跟后者自身的account。而且，我们的:question factory 也包含一个account关联。总数：4 + 4 = 8
现在我们可以创建answer以及comment本身了。总数：8 + 2 = 10。

就是如此！使用create(:comment)创建一个 comment 产生了十条数据库记录。

我们需要多个 account 和不同的 author 来测试一个单独的 comment 吗？不太可能吧。

你可以想象出当我们创建多个 comment 时，比如create_list(:comment, 10)，会发生什么。休斯敦，我们碰上麻烦了。【译者注：电影《阿波罗 13》的经典台词】

遭遇 factory cascade——一个通过嵌套 factory 调用生成过量数据的无法控制的过程。

我们可以把 cascade 用一颗树来描绘：

comment
|
|-- author
|    |
|    |-- account
|
|-- answer
     |
     |-- author
     |    |
     |    |-- account
     |
     |-- question
     |    |
     |    |-- author
     |    |    |
     |    |    |-- account
     |    |
     |    |--account

让我们把这种呈现形式称为 factory 树。稍后会用在我们的分析中。

Fire walk with me

EventProf 仅为我们展示了花费在 factories 上的总时间，也因此能够识别出某些东西不对。然而，我们仍然不知道它们在哪儿，除非去挖掘代码做猜谜游戏。使用 TestProf 医疗包中的另一个工具，就不用这么麻烦了。

第二个分析器登场：FactoryProf。你可以这样来运行它：

$ FPROF=1 bundle exec rspec

报告结果列出了所有 factories 及其使用情况统计：

[TEST PROF INFO] Factories usage

 total      top-level                            name
  1298              2                         account
  1275             69                            city
   524            516                            room
   551            549                            user
   396            117                      membership

524 examples, 0 failures

这里的total和top-level结果有什么区别？total值是一个 factory 被使用生成数据记录的次数，不管显式使用（通过create调用），还是在另一个 factory 内的隐式使用（通过关联关系和回调）；而top-level值仅考虑显式调用。

因此，top-level值和total值之间的明显不同就可能指示了 factory cascade：告知我们一个 factory 更经常从其他 factories 被引用，而非直接调用其自身。

如何准确找出这个“其他 factories”？就用前面讨论过的 factory 树来帮忙！我们来把这颗树平铺展开（使用 pre-order traversal）并把结果列表称为 factory 堆栈：

// factory stack built from the factory tree above
[:comment, :author, :account, :answer, :author, :account, :question, :author, :account, :account]

下面是如何以编程方法构建 factory 堆栈的方式：

每次FactoryBot.create(:thing)被调用时，一个新堆栈就被初始化（使用:smth作为首元素）。
每次另一个 factory 在一个:thing内被使用时，我们把其压入堆栈。

为什么堆栈很棒？正如跟堆栈调用那样，我们可以绘制火焰图！而有什么比火焰图更酷的呢？

FactoryProf 了解如何生成交互的 HTML 火焰图报告，开箱即用。下面是另一个命令行调用：

$ FPROF=flamegraph bundle exec rspec

输出结果包含一个 HTML 报告的路径：

[TEST PROF INFO] FactoryFlame report generated: tmp/test_prof/factory-flame.html

在你浏览器中打开，可以看到类似这样：

我们怎样来阅读它？

每一栏代表一个 factory 堆栈。该栏越宽，该堆栈在测试中耗费的时间越多。root那栏展示了 top-level create调用的总数。

如果你的 FactoryFlame 报告看起来象纽约的大厦轮廓线那样参差不齐，这就是有很多 factory cascade 了（每个“摩天大楼”代表一个 cascade）：

尽管看起来景色很美，但这并非你理想的无 cascade 报告应有的模样。相反，你的目标应该是象荷兰乡村那样平坦的东西：

Doctor, am I going to live?

知道如何发现 cascade 是不够的——我们还需要消灭它们。让我们来考虑有关的几种技术吧。

Explicit associations

涌上心头的第一个做法就是从我们的 factories 移除所有（或几乎所有）关联关系：

factory :comment do
  sequence(:body) { |n| "Awesome comment ##{n}" }
  # do not declare associations
  # author
  # answer
end

采用这个方案，你在使用一个 factory 时必须明确指定所有需要的关联关系：

create(:comment, author: user, answer: answer)

# But!
create(:comment) # => raises ActiveRecord::InvalidRecord

有人可能会问：我们使用 factories 不就是为了每次避免指定所需的参数么？对，没错。用这个方案，factories 变快了，但也更没用了。

Association inference

有时候（通常是在处理 denormalization时）是可能从其他关系推断出关联关系的：

factory :question do
  sequence(:title) { |n| "Awesome question ##{n}" }
  author
  account do
    # infer account from author
    author&.account
  end
end

现在，我们可以编写create(:question)或create(:question, author: user)而不创建一个单独的 account。

我们也能够使用生命周期回调：

factory :question do
  sequence(:title) { |n| "Awesome question ##{n}" }

  transient do
    author :undef
    account :undef
  end

  after(:build) do |question, _evaluator|
    # if only author is specified, set account to author's account
    question.account ||= author.account unless author == :undef
    # if only account is specified, set author to account's owner
    question.author ||= account.owner unless account == :undef
  end
end

这个方案会很有效，但需要很多重构（而且，坦率地讲，让 factories 更难阅读）。

Factory default

而 TestProf 提供了另一种方式来消除 cascade——FactoryDefault。它是一个 factory_bot 的扩展，通过允许你隐式重用 factory 内的记录，来启用更简洁和更不易出错的 DSL，以创建有关联关系的默认值。考虑如下示例：

describe 'PATCH #update' do
  let!(:account) { create_default(:account) }
  let!(:author) { create_deafult(:author) } # implicitly uses account defined above
  let!(:question) { create_default(:question) } # implicitly uses account and author defined above
  let(:answer) { create(:answer) } # implicitly uses question and author defined above

  let(:another_question) { create(:question) } # uses the same account and author
  let(:another_answer) { create(:answer) } # uses the same question and author

  # ...
end

这个方案的主要优势在于你不必修改自己的 factories。你所有需要做的就是把测试中的一些create(…)调用替换为create_default(…)。

另一方面，这个特性也为你的测试带来了一些魔法，所以请谨慎使用，因为测试应该尽可能保持可读性。仅针对 top-level 的实体（比如多租户 App 中的租户）使用是个不错的主意。

Bonus: AnyFixture

到目前为止我们只讨论了 factory cascade。从 TestProf 报告中我们还能看出其他什么呢？

让我们再来看一眼 FactoryProf 报告：

[TEST PROF INFO] Factories usage

 total      top-level                            name
  1298              2                         account
  1275             69                            city
   524            516                            room
   551            549                            user

524 examples, 0 failures

注意到room和user factories 被使用了跟测试用例总数大约相同的次数。因此，在每个用例中两者可能都需要。对于所有用例一次性创建这些记录呢？那么，我们可以使用 fixtures。

由于我们已经有了 factories，重用它们来生成 fixtures 会是很棒的。有请 AnyFixture 登场。

你可以为数据生成使用任何代码块，而 AnyFixture 会在运行结束时负责清理数据库。

AnyFixture 可以很好地跟 RSpec 的 shared contexts 一起工作：

# Activate AnyFixture DSL (fixture) through refinements
using TestProf::AnyFixture::DSL

shared_context "shared user", user: true do
  # You should call AnyFixture outside of transaction to re-use the same
  # data between examples
  before(:all) do
    fixture(:user) { create(:user, room: room) }
  end

  let(:user) { fixture(:user) }
end

然后激活该 shared context：

describe CitiesController, :user do
  before { sign_in user }
  # ...
end

随着 AnyFixture 的启用，FactoryProf 报告会看起来这样：

total      top-level                            name
 1298              2                         account
 1275             69                            city
  8                1                            room
  2                1                            user

524 examples, 0 failures

看起来完美，不是么？

小孩子才对 factories 和 fixtures 做选择，我们全都要！

附记

感谢阅读！

Factories 为你的测试数据生成带来了简单和灵活，但它们非常脆弱——cascade 如幽灵般出现，而重复地数据创建会消费大量的时间。

照顾好你的 factories 吧，定期带它们去看看医生（TestProf）。让测试更快速，开发者就更快乐！

请阅读 TestProf 介绍文章以了解更多该项目和其他使用场景背后的初衷。

TestProf I —— Ruby 慢测试的 “良医圣手”（翻译）

apexy — Sat, 25 Jul 2020 11:13:55 +0800

本文已获得原作者（Vladimir Dementyev）和 Evil Martians 授权许可进行翻译。原文介绍了 TestProf 这个 Evil Martians 出品的强大 Gem。作者通过详细的范例场景和代码演示，说明了 TestProf 怎样对 Ruby 测试进行性能分析，找出慢测试的痛点，以及如何使用其提供的工具箱对慢测试改进，缩短测试运行时间，进行令人愉悦的 Ruby 开发。

我的翻译 Blog 链接在这里：https://xfyuan.github.io/2020/07/testprof-doctor-for-slow-ruby-tests/

原文链接：TestProf: a good doctor for slow Ruby tests — Martian Chronicles, Evil Martians’ team blog
作者：Vladimir Dementyev
站点：Evil Martians ——位于纽约和俄罗斯的 Ruby on Rails 开发人员博客。它发布了许多优秀的文章，并且是不少 gem 的赞助商。

【下面是正文】

概述

编写测试是开发过程的重要部分，尤其是在 Ruby 和 Rails 社区。我们平常不会关注测试用例套件的性能，直到发现自己在对测试“绿点”的等待中已经耗费了太多时间为止。

前言

我已经花费了许多时间用在分析测试套件的性能上，也开发了一些很有用的技术和工具来让测试跑得更快。我把所有这些集合到了一个称为 TestProf 的 Gem 中，这是一个 Ruby 测试的分析工具箱。

The Motivation

慢测试浪费你的时间，降低你的效率。

你可能在扪心自问：“为什么测试性能很重要？”。在给出任何建议之前，让我向你展示一些统计数据吧。

今年早些时候我做过一个小调查，询问了 Ruby 开发者关于其测试偏好的内容。

首先——各位，好消息是——事实证明大多数 Ruby 开发者都确实会编写测试（坦率地说，我并不感到惊讶）。顺便说一句，这就是我之所以如此喜欢 Ruby 社区的原因。

根据这个调查，所有测试套件只有四分之一其运行时间超过 10 分钟——同时只有一半是运行少于 5 分钟。

看起来情况还不坏，对吧？那让我们只来看拥有超过 1000 个测试用例的情况。

现在看起来就差多了：将近一半的测试套件运行都超过了 10 分钟，而几乎 30%——更是超过了 20 分钟。

顺便说一句，我一直工作着的一个典型 Rails 应用有着 6000 ～ 10000 个测试用例。

当然，你不是每次进行一个改动后都必须运行整个测试套件。通常，当我做一个中等大小的功能时，每次提交之前会运行大约 100 个测试用例，而这只花费一分钟左右。但即使这样的“一分钟”也影响到了我的反馈环（参看 Justin Searls 的演讲）从而浪费了我的时间。

尽管如此，在部署周期之内，我们还是必须在使用 CI 服务时运行所有测试。你是否愿意等待好几十分钟（如果队列中有大量的构建，甚至要数小时）来部署一个 hotfix？我很怀疑。

并发地构建会有所帮助，但它们是有代价的。看看下面的柱状图：

例如，我当前的项目上，我们有 5 个并行构建，而平均（每个 job）RSpec 耗时是 2 分 30 秒于 1250 个测试用例上。这意味着我们的 EPM（examples per minute）等于 500.

在未优化之前，800 个测试用例耗时 4 分钟——这仅仅 200 EPM！现在每次构建我们节省了 3～4 分钟。

所以，毫无疑问，慢测试浪费你的时间，拉低你的工作效率。

The Toolbox

好，你已经认识到了自己的测试套件很慢。如何找出它们慢的原因？

让我略过这个介绍视频的所有说辞直接向你介绍 TestProf——一个 Ruby 测试分析工具箱。

TestProf 旨在帮你识别测试套件的瓶颈，并为你提供修复它们的“配方”。

我来给你展示下自己是如何使用它来分析并且改进测试的。

General Profiling

在深入挖掘整个测试套件之前，收集一些常规信息通常很有用。

尝试回答如下问题：

在哪些地方你的测试花费了更多的时间：controllers、models、services 或者 jobs？
最耗时间的 module/method 是什么？

并非那么容易，对吧？

要回答第一个问题，你可以使用 TestProf 的 Tag Profiler，它让你可以收集到根据特别的 RSpec tag 值进行分组的统计信息。RSpec 为测试用例自动添加了type的 tag，所以我们可以这样使用它：

TAG_PROF=type rspec

[TEST PROF INFO] TagProf report for type

          type          time   total  %total   %time           avg

    controller     08:02.721    2822   39.04   34.29     00:00.171
       service     05:56.686    1363   18.86   25.34     00:00.261
         model     04:26.176    1711   23.67   18.91     00:00.155
           job     01:58.766     327    4.52    8.44     00:00.363
       request     01:06.716     227    3.14    4.74     00:00.293
          form     00:37.212     218    3.02    2.64     00:00.170
         query     00:19.186      75    1.04    1.36     00:00.255
        facade     00:18.415      95    1.31    1.31     00:00.193
    serializer     00:10.201      19    0.26    0.72     00:00.536
        policy     00:06.023      65    0.90    0.43     00:00.092
     presenter     00:05.593      42    0.58    0.40     00:00.133
        mailer     00:04.974      41    0.57    0.35     00:00.121
        ...

现在要查找瓶颈即可只关注某些测试类型就够了。

你可能已经了解了常规的 Ruby 分析器，例如 RubyProf 和 StackProf。

TestProf 帮助你在测试套件上无需任何调整就能运行它们：

TEST_RUBY_PROF=1 bundle exec rake test

# or

TEST_STACK_PROF=1 rspec

这些分析器生成的报告可以帮你识别最热的堆栈路径，从而回答第二个问题。

不幸的是，这种类型的分析需要大量资源，让你本来就不那么快的测试套件愈加迟缓。你不得不在测试的一小部分上来运行它，但如何选择是哪一小部分？好吧，只能随机了！

TestProf 包含一个特别的补丁，让你可以运行随机的 RSpec 用例组（或 Minitest 的）：

SAMPLE=10 bundle exec rspec

现在尝试在你 controller 测试的一个样例上运行 StackProf（因为根据上面 TestProf 它们是最慢的）看看输出结果。当我在自己的一个项目上这样做之后，看到了如下内容：

%self     calls  name
20.85       721   <Class::BCrypt::Engine>#__bc_crypt
 2.31      4690  *ActiveSupport::Notifications::Instrumenter#instrument
 1.12     47489   Arel::Visitors::Visitor#dispatch
 1.04    205208   String#to_s
 0.87    531377   Module#===
 0.87    117109  *Class#new

事实证明我们 Sorcery 的 encryption 配置在测试环境跟在生产环境中一样严格。

一个典型的 Rails 应用中，关于时间你会在报告内看到类似这样的一些内容：

TOTAL    (pct)     SAMPLES    (pct)     FRAME
   205  (48.6%)          96  (22.7%)     ActiveRecord::PostgreSQLAdapter#exec_no_cache
    41   (9.7%)          22   (5.2%)     ActiveModel::AttributeMethods::#define_proxy_call
    20   (4.7%)          14   (3.3%)     ActiveRecord::LazyAttributeHash#[]

大量ActiveRecord的东西——意味着大量的数据库操作。想知道如何处理？继续往下看。

Database Interactions

知道你的测试套件在数据库上花费了多少时间吗？先猜猜看，然后使用 TestProf 来计算一下。

我们已经扩展了 Rails 中的 instrumentation（ActiveSupport 的 Notification 和 Instrumentation 功能），所以让我们略过基础来介绍 Event Profiler。

EventProf 在你的测试套件运行中收集检测指标，并提供包含常规信息的报告以及与指定指标有关的前 N 个最慢的组和用例。目前，它自带的仅支持ActiveSupport::Notifications，但其很容易跟你自己的解决方案集成。

要获取有关数据库使用情况的信息，我们可以用sql.active_record事件。然后报告看起来会是这样（很类似于rspec --profile）：

EVENT_PROF=sql.active_record rspec ...

[TEST PROF INFO] EventProf results for sql.active_record

Total time: 00:05.045
Total events: 6322

Top 5 slowest suites (by time):

MessagesController (./spec/controllers/messages_controller_spec.rb:3)–00:03.253 (4058 / 100)
UsersController (./spec/controllers/users_controller_spec.rb:3)–00:01.508 (1574 / 58)
Confirm (./spec/services/confirm_spec.rb:3)–00:01.255 (1530 / 8)
RequestJob (./spec/jobs/request_job_spec.rb:3)–00:00.311 (437 / 3)
ApplyForm (./spec/forms/apply_form_spec.rb:3)–00:00.118 (153 / 5)

对于我目前的项目，耗费在 DB 上的时间量大约是 20%——而这已经是在对其进行了大量优化之后！起初，其耗费时间超过了 30%。

这个指标对于每个项目没有一个单一的最优数字。它高度依赖于你的测试风格：编写更多的单元测试还是集成测试。

我们主要编写集成测试，顺便说一句——20% 并不差（但还能更好）。

什么是数据库耗时偏高的典型原因呢？一言难尽，我来捋一捋其中的部分：

无用的数据生成
过重的测试准备（before/setup hooks）
Factory cascades

第一个是著名的Model.new vs. Model.create问题（或者build_stubbed vs. create在 FactoryBot 中的区别）——你在对 model 的单元测试中可能不需要写入数据库。所以别那样做，好吧？

但如果已经那样做了怎么办？如何找出哪些测试不需要持久化数据？这就该 Factory Doctor 登场了。

当你创建不必要的数据时，FactoryDoctor 会通知你：

FDOC=1 rspec

[TEST PROF INFO] FactoryDoctor report

Total (potentially) bad examples: 2
Total wasted time: 00:13.165

User (./spec/models/user_spec.rb:3)
  validates name (./spec/user_spec.rb:8)–1 record created, 00:00.114
  validates email (./spec/user_spec.rb:8)–2 records created, 00:00.514

不幸的是，FactoryDoctor 不是魔术师（它还在学习中），有时它也会发生“误诊”的事情。

第二个问题比较棘手。考虑这个例子：

describe BeatleSearchQuery do
  # We want to test our searching feature,
  # so we need some data for every example
  let!(:paul) { create(:beatle, name: 'Paul') }
  let!(:ringo) { create(:beatle, name: 'Ringo') }
  let!(:george) { create(:beatle, name: 'George') }
  let!(:john) { create(:beatle, name: 'John') }

  # and about 15 examples here
end

你可能会想：“这里用 fixture 就行了呗”。这貌似个好主意，不过当你正在做一个每天都要更改数十个 model 的大型项目时，就不是那么回事儿了。

另外一个考虑是用before(:all) hook 仅生成数据一次。但这里要提请注意——我们不得不手动清理数据库，因为before(:all)是在事务外运行的。

或者，我们可以把整个组都手动包在一个事务里！这正是 TestProf 的 before_all helper 所做的：

describe BeatleSearchQuery do
  before_all do
    @paul = create(:beatle, name: 'Paul')
    @ringo = create(:beatle, name: 'Ringo')
    @george = create(:beatle, name: 'George')
    @john = create(:beatle, name: 'John')
  end

  # and about 15 examples here
end

如果你想要在不同的组（文件）之间共享 context，考虑使用 Any Fixture，其让你能从代码生成 fixture（比如，使用 factories）。

Factory Cascades

Factory cascade 是一个非常普遍但很少解决的问题，它会让你的整个测试套件陷入困境。

简而言之，它是通过嵌套 factory 调用而生成过度数据的不可控进程。TestProf 知道如何处理它，我们已经写了一篇专栏文章来单独讨论这个主题——你值得看一下。

Background Jobs

除去数据库瓶颈之外，当然还有很多其他瓶颈。我们来说说其中一个。

在测试中有一个 inline 后台任务的普遍做法（例如，Sidekiq::Testing.inline!）。

通常，我们把一些繁重的事情丢进后台任务中，因此无条件地运行所有任务会拖慢运行时间。

TestProf 支持对后台任务耗费时间的分析（目前，仅对 Sidekiq）。只需告诉它要分析sidekiq.inline：

EVENT_PROF=sidekiq.inline bundle exec rspec

现在当你知道了所耗费的准确时间之后，接下来要做什么？简单地关闭 inline 模式很可能会破坏很多测试用例——太多太多以至于无法快速修复。

解决方案就是全局关闭 inline 模式，仅在必要时才使用它。如果你在用 RSpec，则可以这样做：

# Add a shared context
shared_context "sidekiq:inline", sidekiq: :inline do
  around(:each) { |ex| Sidekiq::Testing.inline!(&ex) }
end

# And use it when necessary
it "do some bg", sidekiq: :inline do
  # ...
end

那还是得必须把这些 tag 添加到每个失败的用例上，不是么？抱歉，有 TestProf 在，你确实不必。

在 TestProf 的工具箱中，有一个称为 RSpec Stamp 的特殊工具。它可以自动地添加指定的 tag：

RSTAMP=sidekiq:inline rspec

顺便说一句，RSpec Stamp 在其之下是用了 Ripper 来解析源文件并准确插入 tag 的。

在我们的指南里可以阅读到关于如何从inline!迁移到fake!的完整说明。

附记

TestProf 已经发布在 GitHub 和 rubygems.org，可随时用在你的应用中，帮助你提升测试套件的性能。

本文只是一个 TestProf 的简介，并未涵盖其所有特性。可以跳转到该系列的下一篇：TestProf II: Factory therapy for your Ruby tests 来学习更多关于 TestProf“医生”的工具包，它们能使你的测试更加漂亮优雅，你的 TDD 反馈环更短更快，从而让你成为一个快乐的 Ruby 开发者。

这里是一些额外的资源列表：

TestProf 文档
2017 年 RailsClub Moscow 的“Faster Tests”演讲（视频[俄语]，slides）
2017 年 RubyConfBy 的“Run Test Run”演讲（视频，slides）
Benoit Tigeot 发表的 “Tips to improve speed of your test suite”

2020 时代的 Rails 系统测试（翻译）

apexy — Sun, 19 Jul 2020 16:08:32 +0800

本文已获得原作者（Vladimir Dementyev）和 Evil Martians 授权许可进行翻译。原文介绍了在新的 2020 时代，摒弃了基于 Java 的笨重 Selenium 之后，如何在 Rails 下构建基于浏览器的高效系统测试。作者对于系统测试概念进行了详细阐述，演示了具体配置的范例和运行效果，对 Docker 开发环境也有专业级别的涵盖。非常推荐。我的翻译 Blog 链接在这里：https://xfyuan.github.io/2020/07/proper-browser-testing-in-rails/

原文链接：System of a test: Proper browser testing in Ruby on Rails — Martian Chronicles, Evil Martians’ team blog
作者：Vladimir Dementyev
站点：Evil Martians ——位于纽约和俄罗斯的 Ruby on Rails 开发人员博客。它发布了许多优秀的文章，并且是不少 gem 的赞助商。

【下面是正文】

发现 Ruby on Rails 应用中端到端浏览器测试的最佳实践集合，并在你的项目上采用它们。了解如何摒弃基于 Java 的 Selenium，转而使用更加精简的 Ferrum-Cuprite 组合，它们能直接通过纯 Ruby 方式来使用 Chrome DevTools 的协议。如果你在使用 Docker 开发环境——本文也有涵盖。

Ruby 社区对于测试饱含激情。我们有数不胜数的测试库，有成千上万篇关于测试主题的博客文章，甚至为此有一个专门的播客。更可怕的是，下载量排在前三名的 Gem 也都是有关 RSpec 测试框架的！

我相信，Rails，是 Ruby 测试兴盛背后的原因之一。这个框架让测试的编写尽可能地成为一种享受了。多数情况下，跟随着 Rails 测试指南的教导就已足够（起码在刚开始的时候）。但事情总有例外，而在我们这里，就是系统测试。

对 Rail 应用而言，编写和维护系统测试很难被称为“惬意的”。我在处理这个问题上，自 2013 年的第一次 Cucumber 驱动测试算起，已经逐步改进了太多。而今天，到了 2020 年，我终于可以来跟大家分享一下自己当前（关于测试）的设置了。本文中，我将会讨论以下几点：

系统测试概述
使用 Cuprite 进行现代系统测试
配置范例
Docker 化的系统测试

系统测试概述

“系统测试”是 Rails 世界中对于自动化端到端测试的一种通常称谓。在 Rails 采用这个名称之前，我们使用诸如功能测试、浏览器测试、甚至验收测试等各种叫法（尽管后者在意思上有所不同）。

如果我们回忆下测试金字塔（或者就金字塔），系统测试是处于非常靠上的位置：它们把整个程序视为一个黑盒，通常模拟终端用户的行为和预期。而这就是在 Web 应用程序情况下，为什么我们需要浏览器来运行这些测试的原因（或者至少是类似 Rack Test 的模拟器）。

我们来看下典型的系统测试架构：

我们需要管理至少三个“进程”（它们有些可以是 Ruby 线程）：一个运行我们应用的 Web 服务端，一个浏览器，和一个测试运行器。这是最低要求。实际情况下，我们通常还需要另一个工具提供 API 来控制浏览器（比如，ChromeDriver）。一些工具尝试通过构建特定浏览器（例如 capybara-webkit 和 PhantomJS）来简化此设置，并提供开箱即用的此类 API，但它们在对真正浏览器的兼容性“竞争”中都败下阵来，没能幸免于难。

当然，我们需要添加少量 Ruby Gem 测试依赖库——来把所有碎片都粘合起来。更多的依赖库会带来更多的问题。例如，Database Cleaner 在很长时间内都是一个必备的库：我们不能使用事务来自动回滚数据库状态，因为每个线程都是用自己独立的连接。我们不得不针对每张表使用TRUNCATE ...或DELETE FROM ...来代替，这会相当慢。我们通过在所有线程中使用一个共享连接解决了这个问题（使用 TestProf extension）。Rails 5.1 也发布了一个现成的类似功能。

这样，通过添加系统测试，我们增加了开发环境和 CI 环境的维护成本，以及引入了潜在的故障或不稳定因素：由于复杂的设置，flakiness 是端到端测试中最常见的问题。而大多数这些 flakiness 来自于跟浏览器的通信。

尽管通过在 Rails 5.1 中引入系统测试简化了浏览器测试，它们仍然需要一些配置才能平滑运行：

你需要处理 Web drivers（Rails 假设你使用 Selenium）。
你可以自己在容器化环境中配置系统测试（例如，象这篇文章中的做法）。
配置不够灵活（例如，屏幕快照的路径）

让我们来转到代码层面吧，看看在 2020 时代如何让你的系统测试更有乐趣！

使用 Cuprite 进行现代系统测试

默认情况下，Rails 假设你会使用 Selenium 来跑系统测试。Selenium 是一个实战验证过的 Web 浏览器自动化软件。它旨在为所有浏览器提供一个通用 API 以及最真实的体验。在模拟用户浏览器交互方面，唯有有血有肉的真人才比它做得更好些。

不过，这种能力不是没有代价的：你需要安装特定浏览器的驱动，现实交互的开销在规模上是显而易见的（例如，Selenium 的测试通常都相当慢）。

Selenium 已经是很久以前发布的了，那时浏览器还不提供任何内置自动化测试兼容性。这么多年过去了，现在的情况已经大不相同，Chrome 引入了 CDP 协议。使用 CDP，你可以直接操作浏览器的 Session，不再需要中间的抽象层和工具。

从那以后，涌现了好多利用 CDP 的项目，包括最著名的——Puppeteer，一个 Node.js 的浏览器自动化库。那么 Ruby 世界呢？是 Ferrum，一个 Ruby 的 CDP 库，尽管还相当年轻，也提供了不逊色于 Puppeteer 的体验。而对我们更重要的是，它带来了一个称为 Cuprite 的伙伴项目——使用 CDP 的纯 Ruby Capybara 驱动。

我从 2020 年初才开始积极使用 Cuprite 的（一年前我尝试过，但在 Docker 环境下有些问题），从未让我后悔过。设置系统测试变得异常简单（全部所需仅 Chrome 而已），而且执行是如此之快，以至于在从 Selenium 迁移过来之后我的一些测试都失败了：它们缺乏合适的异步期望断言，在 Selenium 中能通过仅仅是因为 Selenium 太慢。

让我们来看下我最近工作上所用到 Cuprite 的系统测试配置。

注释过的配置范例

这个范例来自于我最近的开源 Ruby on Rails 项目——AnyCable Rails Demo。它旨在演示如何跟 Rails 应用一起使用刚刚发布的 AnyCable 1.0，但我们也可用于本文——它有很好的系统测试覆盖着。

这个项目使用 RSpec 及其系统测试封装器。其大部分也是可以用在 Minitest 上的。

让我们从一个足以在本地机器上运行的最小示例开始。其代码放在 AnyCable Rails Demo 的 demo/dockerless 分支上。

首先来快速看一眼 Gemfile：

group :test do
  gem 'capybara'
  gem 'selenium-webdriver'
  gem 'cuprite'
end

什么？为什么需要selenium-webdriver，如果我们根本不用 Selenium 的话？事实证明，Rails 要求这个 gem 独立于你所使用的驱动而存在。好消息是，这已经被修复了，我们有望在 Rails 6.1 中移除这个 gem。

我把系统测试的配置放在多个文件内，位于spec/system/support目录，使用专门的system_helper.rb来加载它们：

spec/
  system/
    support/
      better_rails_system_tests.rb
      capybara_setup.rb
      cuprite_setup.rb
      precompile_assets.rb
      ...
  system_helper.rb

我们来看下上面这个列表中的每个文件都是干嘛的。

system_helper.rb

system_helper.rb文件包含一些针对系统测试的通用 RSpec 配置，不过，通常而言，都如下面这样简单：

# Load general RSpec Rails configuration
require "rails_helper.rb"

# Load configuration files and helpers
Dir[File.join(__dir__, "system/support/**/*.rb")].sort.each { |file| require file }

然后，在你的系统测试中，使用require "system_helper"来激活该配置。

我们为系统测试使用了一个单独的 helper 文件和一个 support 文件夹，以避免在我们只需运行一个单元测试时加载所有多余的配置。

capybara_setup.rb

这个文件包含针对 Capybara 框架的配置：

# spec/system/support/capybara_setup.rb

# Usually, especially when using Selenium, developers tend to increase the max wait time.
# With Cuprite, there is no need for that.
# We use a Capybara default value here explicitly.
Capybara.default_max_wait_time = 2

# Normalize whitespaces when using `has_text?` and similar matchers,
# i.e., ignore newlines, trailing spaces, etc.
# That makes tests less dependent on slightly UI changes.
Capybara.default_normalize_ws = true

# Where to store system tests artifacts (e.g. screenshots, downloaded files, etc.).
# It could be useful to be able to configure this path from the outside (e.g., on CI).
Capybara.save_path = ENV.fetch("CAPYBARA_ARTIFACTS", "./tmp/capybara")

该文件也包含一个对于 Capybara 很有用的补丁，其目的我们稍后揭示：

# spec/system/support/capybara_setup.rb

Capybara.singleton_class.prepend(Module.new do
  attr_accessor :last_used_session

  def using_session(name, &block)
    self.last_used_session = name
    super
  ensure
    self.last_used_session = nil
  end
end)

Capybara.using_session让你能够操作不同的浏览器 session，从而在单个测试场景内操作多个独立 session。这在测试实时功能时尤其有用，例如使用 WebSocket 的功能。

该补丁跟踪上次使用的 session 名称。我们会用这个信息来支持在多 session 测试中获取失败情况下的屏幕快照。

cuprite_setup.rb

这个文件负责配置 Cuprite：

# spec/system/support/cuprite_setup.rb

# First, load Cuprite Capybara integration
require "capybara/cuprite"

# Then, we need to register our driver to be able to use it later
# with #driven_by method.
Capybara.register_driver(:cuprite) do |app|
  Capybara::Cuprite::Driver.new(
    app,
    **{
      window_size: [1200, 800],
      # See additional options for Dockerized environment in the respective section of this article
      browser_options: {},
      # Increase Chrome startup wait time (required for stable CI builds)
      process_timeout: 10,
      # Enable debugging capabilities
      inspector: true,
      # Allow running Chrome in a headful mode by setting HEADLESS env
      # var to a falsey value
      headless: !ENV["HEADLESS"].in?(%w[n 0 no false])
    }
  )
end

# Configure Capybara to use :cuprite driver by default
Capybara.default_driver = Capybara.javascript_driver = :cuprite

我们也为常用 Cuprite API 方法定义了一些快捷方式：

module CupriteHelpers
  # Drop #pause anywhere in a test to stop the execution.
  # Useful when you want to checkout the contents of a web page in the middle of a test
  # running in a headful mode.
  def pause
    page.driver.pause
  end

  # Drop #debug anywhere in a test to open a Chrome inspector and pause the execution
  def debug(*args)
    page.driver.debug(*args)
  end
end

RSpec.configure do |config|
  config.include CupriteHelpers, type: :system
end

下面你可以看到一个#debug帮助方法如何工作的演示：

better_rails_system_tests.rb

这个文件包含一些有关 Rails 系统测试内部的补丁以及通用配置（代码注释有详细解释）：

# spec/system/support/better_rails_system_tests.rb

module BetterRailsSystemTests
  # Use our `Capybara.save_path` to store screenshots with other capybara artifacts
  # (Rails screenshots path is not configurable https://github.com/rails/rails/blob/49baf092439fc74fc3377b12e3334c3dd9d0752f/actionpack/lib/action_dispatch/system_testing/test_helpers/screenshot_helper.rb#L79)
  def absolute_image_path
    Rails.root.join("#{Capybara.save_path}/screenshots/#{image_name}.png")
  end

  # Make failure screenshots compatible with multi-session setup.
  # That's where we use Capybara.last_used_session introduced before.
  def take_screenshot
    return super unless Capybara.last_used_session

    Capybara.using_session(Capybara.last_used_session) { super }
  end
end

RSpec.configure do |config|
  config.include BetterRailsSystemTests, type: :system

  # Make urls in mailers contain the correct server host.
  # It's required for testing links in emails (e.g., via capybara-email).
  config.around(:each, type: :system) do |ex|
    was_host = Rails.application.default_url_options[:host]
    Rails.application.default_url_options[:host] = Capybara.server_host
    ex.run
    Rails.application.default_url_options[:host] = was_host
  end

  # Make sure this hook runs before others
  config.prepend_before(:each, type: :system) do
    # Use JS driver always
    driven_by Capybara.javascript_driver
  end
end

precompile_assets.rb

这个文件负责在运行系统测试之前预编译 assets（我不在这儿粘贴它的完整代码，只给出最有趣的部分）：

RSpec.configure do |config|
  # Skip assets precompilcation if we exclude system specs.
  # For example, you can run all non-system tests via the following command:
  #
  #    rspec --tag ~type:system
  #
  # In this case, we don't need to precompile assets.
  next if config.filter.opposite.rules[:type] == "system" || config.exclude_pattern.match?(%r{spec/system})

  config.before(:suite) do
    # We can use webpack-dev-server for tests, too!
    # Useful if you working on a frontend code fixes and want to verify them via system tests.
    if Webpacker.dev_server.running?
      $stdout.puts "\n⚙️  Webpack dev server is running! Skip assets compilation.\n"
      next
    else
      $stdout.puts "\n🐢  Precompiling assets.\n"

      # The code to run webpacker:compile Rake task
      # ...
    end
  end
end

为什么要手动预编译 assets 呢，如果 Rails 能够自动为你做这事的话？问题在于 Rails 预编译 assets 是惰性的（比如，在你首次请求一个 asset 的时候），这会使你的第一个测试用例非常非常慢，甚至碰到随机超时的异常。

另一个我想提请注意的是使用 Webpack dev server 进行系统测试的能力。这在当你进行艰苦的前端代码重构时相当有用：你可以暂停一个测试，打开浏览器，编辑前端代码并看到它被热加载了！

Docker 化的系统测试

让我们把自己的配置提升到更高的层次，使其兼容我们的 Docker 开发环境。Docker 化版本的测试设置在 AnyCable Rails Demo 代码库的默认分支上，可随意查看，不过下面我们打算涵盖那些有意思的内容。

Docker 下设置的主要区别是我们在一个单独的容器中运行浏览器实例。可以把 Chrome 添加到你的基础 Rails 镜像上，或者可能的话，甚至从容器内使用主机的浏览器（这可以用 Selenium and ChromeDriver 做到）。但是，在我看来，为docker-compose.yml定义一个专用的浏览器 service 是一种更正确的 Docker 式方式来干这个。

目前，我用的是来自 browserless.io 的 Chrome Docker 镜像。它带有一个好用的 Debug 查看器，让你能够调试 headless 的浏览器 session（本文最后有一个简短的视频演示）：

services:
  # ...
  chrome:
    image: browserless/chrome:1.31-chrome-stable
    ports:
      - "3333:3333"
    environment:
      # By default, it uses 3000, which is typically used by Rails.
      PORT: 3333
      # Set connection timeout to avoid timeout exception during debugging
      # https://docs.browserless.io/docs/docker.html#connection-timeout
      CONNECTION_TIMEOUT: 600000

把CHROME_URL: http://chrome:3333添加到你的 Rails service 环境变量，以后台方式运行 Chrome：

docker-compose up -d chrome

现在，如果提供了 URL，我们就需要配置 Cuprite 以和远程浏览器一起工作：

# cuprite_setup.rb

# Parse URL
# NOTE: REMOTE_CHROME_HOST should be added to Webmock/VCR allowlist if you use any of those.
REMOTE_CHROME_URL = ENV["CHROME_URL"]
REMOTE_CHROME_HOST, REMOTE_CHROME_PORT =
  if REMOTE_CHROME_URL
    URI.parse(REMOTE_CHROME_URL).yield_self do |uri|
      [uri.host, uri.port]
    end
  end

# Check whether the remote chrome is running.
remote_chrome =
  begin
    if REMOTE_CHROME_URL.nil?
      false
    else
      Socket.tcp(REMOTE_CHROME_HOST, REMOTE_CHROME_PORT, connect_timeout: 1).close
      true
    end
  rescue Errno::ECONNREFUSED, Errno::EHOSTUNREACH, SocketError
    false
  end

remote_options = remote_chrome ? { url: REMOTE_CHROME_URL } : {}

上面的配置假设当CHROME_URL未被设置或者浏览器未响应时，使用者想使用本地安装的 Chrome。

我们这样做以便让配置向下兼容本地的配置（我们一般不强迫每个人都使用 Docker 作为开发环境；让拒绝使用 Docker 者为其独特的本地设置而受苦吧😈）。

我们的驱动注册现在看起来是这样的：

# spec/system/support/cuprite_setup.rb

Capybara.register_driver(:cuprite) do |app|
  Capybara::Cuprite::Driver.new(
    app,
    **{
      window_size: [1200, 800],
      browser_options: remote_chrome ? { "no-sandbox" => nil } : {},
      inspector: true
    }.merge(remote_options)
  )
end

我们也需要更新自己的#debug帮助方法以打印 Debug 查看器的 URL，而不是尝试去打开浏览器：

module CupriteHelpers
  # ...

  def debug(binding = nil)
    $stdout.puts "🔎 Open Chrome inspector at http://localhost:3333"
    return binding.pry if binding

    page.driver.pause
  end
end

由于浏览器是运行在一个不同的“机器”上，因此它应该知道如何到达测试服务端（其不再是localhost）。

为此，我们需要配置 Capybara 服务端的 host：

# spec/system/support/capybara_setup.rb

# Make server accessible from the outside world
Capybara.server_host = "0.0.0.0"
# Use a hostname that could be resolved in the internal Docker network
# NOTE: Rails overrides Capybara.app_host in Rails <6.1, so we have
# to store it differently
CAPYBARA_APP_HOST = `hostname`.strip&.downcase || "0.0.0.0"
# In Rails 6.1+ the following line should be enough
# Capybara.app_host = "http://#{`hostname`.strip&.downcase || "0.0.0.0"}"

最后，让我们对better_rails_system_tests.rb做一些调整。

首先，我们来让 VS Code 中的屏幕快照通知变得可点击🙂（Docker 绝对路径与主机系统是不同的）：

# spec/system/support/better_rails_system_tests.rb

module BetterRailsSystemTests
  # ...

  # Use relative path in screenshot message
  def image_path
    absolute_image_path.relative_path_from(Rails.root).to_s
  end
end

其次，确保测试都使用了正确的服务端 host（这在 Rails 6.1 中已经被修复了）：

# spec/system/support/better_rails_system_tests.rb

config.prepend_before(:each, type: :system) do
  # Rails sets host to `127.0.0.1` for every test by default.
  # That won't work with a remote browser.
  host! CAPYBARA_APP_HOST
  # Use JS driver always
  driven_by Capybara.javascript_driver
end

In too Dip

如果你使用 Dip 来管理 Docker 开发环境（我强烈建议你这么做，它使你获得容器的强大能力，而无需记忆所有 Docker CLI 命令的成本付出），那么你可以通过在dip.yml中添加自定义命令和在docker-compose.yml中添加一个额外 service 定义，来避免手动加载chrome service：

# docker-compose.yml

# Separate definition for system tests to add Chrome as a dependency
rspec_system:
  <<: *backend
  depends_on:
    <<: *backend_depends_on
    chrome:
      condition: service_started

# dip.yml
rspec:
  description: Run Rails unit tests
  service: rails
  environment:
    RAILS_ENV: test
  command: bundle exec rspec --exclude-pattern spec/system/**/*_spec.rb
  subcommands:
    system:
      description: Run Rails system tests
      service: rspec_system
      command: bundle exec rspec --pattern spec/system/**/*_spec.rb

现在，我使用如下命令来运行系统测试：

dip rspec system

就是这样了！

最后，让我向你展示一下如何使用 Browserless.io 的 Docker 镜像的 Debug 查看器进行调试：

DHH 最新博客——“雄伟巨石”可以成为“城堡”

apexy — Mon, 13 Apr 2020 14:37:09 +0800

DHH 在 2020.04.08 发表了一篇最新博客“The Majestic Monolith can become The Citadel”，继续讨论对微服务的一点看法，提出了一种与微服务相对的“城堡”模式。在推上也引发了不少关注，搜关键字“The Majestic Monolith”就能看到很多。这是原文链接：https://m.signalvnoise.com/the-majestic-monolith-can-become-the-citadel/

我按照个人理解，粗略翻译了一下。大家可以对照原文来看，如有翻译不准确的地方，请在回复中提出来。

[翻译]

“雄伟巨石”可以成为“城堡”

大多数的 Web 应用应该都是从一块“雄伟巨石”开始其生涯的：一个单一代码库做其所需的所有事儿。与之相对的是一群 Service，不管这些 Service 是“微”还是“大一点”的，都试图把应用切成孤岛，每个仅做整体工作的一小片而已。

大多数的 Web 应用都将以“雄伟巨石”形态在其一生中都能持续提供很好的服务。这种模式的上限很高，比大部分人幻想成为架构师时所能想象的要高得多。

但是，尽管如此，“雄伟巨石”仍然会有需要一些帮助的那一天。也许你正在与庞大的团队打交道，其中的人们相互磕磕绊绊（即使这样，别忘了有很多非常大的组织依然在使用 monorepo 模式！）。或者你终究会遇到极端负载下的性能或可用性问题，这在“雄伟巨石”的技术选择范围内无法轻松解决。你的第一直觉将是改进“雄伟巨石”直到其能够应对问题，做了这一切而没成功时，你才会考虑下一步。

下一步就是“城堡”，保持“雄伟巨石”在中心位置，但用一系列的“基地”对其支援，每个分离出应用程序职能一个小的子集。“基地”使得“雄伟巨石”得以卸下其不同行为的一个切片，（这些不同行为）要么是出于组织原因，要么是出于性能或实现的原因。

一个在 Basecamp 的这种例子是我们的旧 chat 应用 Campfire。它是在 2005 年构建的，那时 Ajax 和其他 JavaScript 技术都还很新颖，所以它基于 polling 而不是现代 chat app 目前使用的长连接。这意味着每个客户端连接到系统都会每三秒触发一个请求来询问“是否有我的新消息？”。大多数这些请求都会回答“不，没有”，但为了获取这个答案，你仍然不得不对请求进行身份验证，查询数据库，等等。

与应用程序的其他相比，这个服务的性能特征大不相同。在任何给定时间，它都将占所有请求的 99%。它也是一个确实很简单的系统。在 Ruby 中，它仅仅 20 行代码长度而已，如果我没记错的话。换句话说，这是一个极好的“基地”候选人！

所以我们就（为它）构筑了一个“基地”。这么些年来，在日光下使用每种高性能编程语言来重写这种“基地”成为了我们的乐趣，因为通常只用短短几百行代码就能搞定，不管什么语言。所以我们使用了 C，C++，Go，Erlang，还有些我都忘记了。

但这显然是一种“基地”！应用程序的其他部分继续作为 Ruby on Rails 构建的“雄伟巨石”。我们没有试图把整个 app 切成小的 Service，每个以不同语言来编写。不，我们只是分离出一个单独的“基地”。这是一个“城堡”的建设。

随着越来越多的人们意识到对于微服务的追逐会走上一条死胡同，“钟摆将会再摆动回来“。“雄伟巨石”在这儿等待着微服务的“难民”。如果他们确实做到了大型应用程序的规模，那么“城堡”这种可以扩展的模式足以让你安心。

Travis CI 被收购了？

apexy — Wed, 30 Jan 2019 11:10:24 +0800

Travis CI joins the Idera family

https://blog.travis-ci.com/2019-01-23-travis-ci-joins-idera-inc

但承诺对 open source project 的支持不变

What impact will this have on open source?

Open source is at the heart of Travis CI. We will continue to maintain a free, hosted service for open source projects, and will keep building features for the open source community. Additionally, our code will stay open source and under an MIT license. This is who we are, this is what made us successful.

为什么我偏爱 Ember.js 胜过 Angular 和 React.js

apexy — Sun, 26 Mar 2017 00:28:42 +0800

为什么我偏爱 Ember.js 胜过 Angular 和 React.js

前几天看到了这篇文章：Why I prefer Ember.js over Angular & React.js，觉得对于国内期望了解 Ember.js 的开发者来说是一个不错的介绍。于是和该文的作者 Paul Shan 联系取得翻译的授权，翻译了过来。

文章也放在我的 Blog 上：为什么我偏爱 Ember.js 胜过 Angular 和 React.js

译文如下：

从我开始写 JavaScript 已经有 5 年了。无论是开发项目，指导别人，还是发布文章，JavaScript 都给了我极大的满足感。感谢 JavaScript！

在过去 5 年里我使用过很多 JavaScript 框架，不管做后端还是前端。但 Ember 从 2015 年中期就从我的开发世界中消失了。幸运的是 1 个月前机缘凑巧我又参加了一个用 Ember 做的前端项目。起初我并不太在意这点，只把它当作不过又一个日常开发而已。但随着项目的深入我开始思考自己关于这三个前端框架的体验，并在今天把它记录下来。

声明

该文并非是要抨击 Angular 或 React。
该文并非要很深入探讨技术层面的部分，而是作为一个开发人员对其真实使用体验的吐露。
标题中我使用了“偏爱”而非“推荐”的字眼，因为“推荐”往往要和具体项目具体场景相关，而“偏爱”则是一种更普适性的描述。

Ember 令人满意之所在

原生感受

说实话，最近几年来我对 JavaScript 越来越不满。我不喜欢有人试图用工程的模式来对待 JavaScript。我喜爱 JavaScript 就仅仅是 JavaScript 而已。这也是我为什么不喜欢 TypeScript，以及 Angular 2。我看不到任何用处来多学习另一门语言，只为了试图引入一些丑陋的类（我知道是可选的）和语法。React 至少在这一点上做的比 Angular 2 好一些，但你依旧要面对 jsx 的问题。

相反，Ember 使用了纯 JavaScript。你只用写 JavaScript。Ember 提供了很多 api，却没有额外的语法。这让我作为 JavaScript 开发者而言感觉很棒。

约定大于配置

相信我，尽可能地减少配置相关代码对你的项目将有巨大的好处。首先，代码会变得少而清爽。其次，约定将是通用的，任何新加入的开发者都能了解发生了什么。对于那些之前从没有使用过 Ember 的人来说，只要你遵循了约定来命名文件和变量，Ember 就能自己处理好剩下的事情。

所见过的最好文档

Ember guides 和 Ember API 的文档可能是我开发生涯中见过的最好技术文档。即使是一个初学者都能很容易理解并上手。Ember 的官方论坛对于解决疑问也很有帮助。

最好的构建体验

Ember-CLI 是 Ember 的一大杀器。即使 Angular 都试图借鉴 Ember 的这一工具来开发自己的 CLI。使用 ember-cli 你可以快速构建一个预定义好目录文件架构的项目，而这样的架构是经过社区的讨论和实践所验证过的。当项目开始构建时，无论团队是否对此有经验，都完全不用担心有没有遵循最佳实践的问题。对于 React 而言这里就可能存在风险，因为它只是一个库并非是一个框架。

强制性的最佳实践

即使你的团队中有很棒的开发者，有时候迫于上线的压力他们也会写出坏的代码。而 Ember 会至少在某些层面上强制性地让你采取最佳实践的方式。举个例子，你不应该把业务逻辑写到模版中。Ember 的模版里只可以使用迭代 iteration 和带布尔参数的 helper 帮助方法，这样你就根本别考虑在模版里写业务逻辑的事儿了。

开发效率的提升

我知道，在三个框架里 Ember 可能是学习曲线最陡也最难学的那一个。但是一旦你掌握了它，你就能开发一个项目超快，远胜过 Angular 或 React。“约定大于配置”和 ember-cli 就是最主要的两个原因。

团队工作

如果你公司的所有团队（甚至即使有人不在公司办公）是在开发多个 Ember 项目，使用 ember-cli 构建工具，那么他们每个人的项目目录文件架构会非常相似，而且可以几乎不花费什么时间成本就进行项目的切换，并立刻投入开发和提交代码。这实际变相提高了公司实际上的开发效率。

不属于公司只属于社区

Angular 属于 Google，React 属于 Facebook。而 Ember 来自于社区，也只为了社区。Ember 核心开发团队的开发者们都来自于各自公司实际 Ember 项目的成员，这恰好是 Ember 的最大不同之处：他们不仅是框架的开发者，更是框架的使用者。这让他们能始终贴近现实，紧接地气。

友好的版本发布

我幸运地在 Angular 2 发布时已经离开了之前的 Angular 项目，但我的朋友要为项目升级到 Angular 2 头疼和抓狂了。与此相反，Ember 2 发布时没有任何变化。是的，你没听错。它没有任何变化。Ember 1.13.0 和 2.0 在使用上完全相同，因为 Ember 是采取渐进式的策略来对 1.x 开放新功能，以便让使用 Ember 的实际项目能进行完全无痛地升级。这正是 Ember 核心团队成员“不仅是框架的开发者，更是框架的使用者”的最好体现。

Ember 没有缺点了吗？

任何事物都有两面性，Ember 也不例外。Ember 也有自己的缺点，诸如陡峭的学习曲线，稍慢的页面渲染，框架体积较大等。已经有很多的技术文章对这些框架进行过比较了。但本文更多的是在开发实践体验上我个人的一些感受。我相信这些框架中不管选用哪一个，就技术而言都能帮你完成项目。但还有一些除此之外的因素影响到你项目的实施和进展。在考虑了各种实际情况、业务、场景之后，你就可以做出最佳的决策来启动项目了。

抱怨 GitLab 安装麻烦的可看看这个。。

apexy — Sat, 22 Jun 2013 22:22:12 +0800

看到坛子里有人在抱怨 GitLab 不好安装。

正好我最近刚写了篇 blog《CentOS6.4 下安装 GitLab5.2》，是自动脚本化安装。脚本也放在了 github 上（地址在 blog 文内），有需要的朋友应该可以借鉴一下。

BTW，那个帖子里有人回复推荐了一个自动化安装脚本：github.com/mattias-ohlsson/gitlab-installer。正巧我当时也是参考了这个。但是要说一句，它是针对当时 GitLab 5.0 的，现在最新的 5.2 已经不支持了。我的脚本可以支持到 5.2。

~~blog url: yxfilm.us/blog/2013/06/centos6-4下安装gitlab5-2/~~

坛子里 url 含中文名会识别错，改用这个：

blog url: http://yxfilm.us/blog/archives/2013/06/72

apexy (apexy)

深入 Rails 的 Zeitwerk 模式

Goodbye #const_missing, Hello #autoload

Loading a single file

Implicit namespaces

Explicit namespaces

Conclusion

Rails7 的 Zeitwerk 模式解惑

How classic autoloading works?

How zeitwerk autoloading works?

Common Problems resolved by zeitwerk mode

1、When Constants aren't Missed

With Classic Mode

With Zeitwerk Mode

2、Autoloading within Singleton Classes

With classic mode

With zeitwerk mode

3、Autoloading and Single-table Inheritance (STI)

With classic mode

With zeitwerk mode

Conclusion

References

Rails 6.1 正式发布了～！

TestProf 文档中文版上线（和跟作者 Vladimir 交流的过程及感受）

TestProf II —— Ruby 测试的 “工厂疗法”（翻译）

概述

前言

Crumbling factories

The name of the game is “cascade”

Fire walk with me

Doctor, am I going to live?

Explicit associations

Association inference

Factory default

Bonus: AnyFixture

附记

TestProf I —— Ruby 慢测试的 “良医圣手”（翻译）

概述

前言

The Motivation

The Toolbox

General Profiling

Database Interactions

Factory Cascades

Background Jobs

附记

2020 时代的 Rails 系统测试（翻译）

系统测试概述

使用 Cuprite 进行现代系统测试

注释过的配置范例

system_helper.rb

capybara_setup.rb

cuprite_setup.rb

better_rails_system_tests.rb

precompile_assets.rb

Docker 化的系统测试

In too Dip

DHH 最新博客——“雄伟巨石”可以成为“城堡”

“雄伟巨石”可以成为“城堡”

Travis CI 被收购了？

为什么我偏爱 Ember.js 胜过 Angular 和 React.js

为什么我偏爱 Ember.js 胜过 Angular 和 React.js

声明

Ember 令人满意之所在

原生感受

约定大于配置

所见过的最好文档

最好的构建体验

强制性的最佳实践

开发效率的提升

团队工作

不属于公司只属于社区

友好的版本发布

Ember 没有缺点了吗？

相关文章

抱怨 GitLab 安装麻烦的可看看这个。。

Goodbye `#const_missing`, Hello `#autoload`