Question

我们有很大的应用程序，目前我们正在从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。然后在必要时包括它。但不确定这种方法是否合适。

Answer 1

好的，所以几乎总是存在几乎恒定的数据。在生产中，在您的开发机器上，在每次测试运行等等。然后您有更改的数据;在生产中，它是用户生成的数据，在您需要模拟它的测试中。

现在我们只需要为每项工作使用正确的工具。几乎不变的数据是种子的用途，而模拟不断变化的数据则是工厂闪耀的地方。

Rails提供的种子并不是那么好，但是由于有几颗宝石可以变得非常好。

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

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

这样，您不需要那么多重叠的概念（灯具等）。种子处理常量数据，工厂主要处理特定于测试的数据。希望它会有所帮助。

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

FactoryGirl，Rspec和复杂的数据库结构

1 个答案: