2

我们有非常大的 Rails 应用程序，目前我们正在从 TestUnit/fixtures 切换到 Rspec/FactoryGirl。我们的数据库有很多“系统”表，其中数据要么是不变的，要么很少更新。例如

user_types
ID  NAME                       ...
1   System Adminisrator        ...
2   Organization Administrator ...
....
9   Mega Administrator         ...

此外，我们还有很多配置表和它们之间的长引用。例如：

master_organizations many-to-many organizations has_many 
plan_years has_many products has_many plans

organizations has_many employees ... and so on

我们需要在所有规范运行之前配置所有系统表和至少一个组织。然后，如果需要，每个套件都可以向 db 添加其他数据。

所以问题是如何构建一个对开发人员可读的漂亮、复杂和灵活的结构？今天对我们来说最接近的解决方案是将数据库结构创建移动到单独的文件中：为系统表、配置表等创建 shared_contexts。然后在必要时包括它。但不确定这种方法是否好。

4

1 回答 1

2

好的，所以您拥有几乎始终存在的几乎恒定的数据。在生产中，在您的开发机器上，在每次测试运行等中。然后您的数据会发生变化；在生产中它是您的用户生成的数据，在测试中您需要模拟它。

现在我们只需要为每项工作使用正确的工具。几乎恒定的数据是种子的用武之地，而模拟不断变化的数据是工厂大放异彩的地方。

Rails 提供的种子不是那么好，但多亏了几颗宝石，它们可以变得非常好。

SeedFu为您提供了一个很好的 DSL，用于定义在后续运行中不会重复的种子。例如

User.seed_once(:email,
  { :email => "jon@example.com",   :name => "Jon"   },
  { :email => "emily@example.com", :name => "Emily" }
)

Seedbank为种子文件提供了一些急需的结构。它覆盖了默认rake db:seed任务，并为在任何地方都不需要的种子提供了特定于环境的文件夹。所以你会有类似的东西：

db/seeds/
  development/
    users.seeds.rb
  organizations.seeds.rb
  user_types.seeds.rb

这样，您就不需要有那么多重叠的概念（夹具等）。种子处理恒定的数据，工厂主要处理特定于测试的数据。希望它会有一些用处。

注意：如果您的测试可以是独立的，而不依赖于种子或其他数据库状态，那当然会更好。但实际上，您的某些数据与围绕它的模型一样，是您应用程序不可或缺的一部分。我们的方法可能会带来一些麻烦（总是在迁移、数据库清理策略上运行种子），但到目前为止它对我们有效。调整适合您用例的部分。

于 2014-05-28T10:57:13.253 回答