1

我只是在寻找资深/更有经验的 Ruby/Rails 开发人员的答案，因为我认为这是一个更高级的问题。

我正在研究一个宝石，它为 AR 模型添加了一些行为。我必须针对许多不同的关联（has_many、habtm、has_one 等）测试它，并且我还必须测试为关联传递不同选项时的行为（例如：foreign_key）。现在有了所有这些不同的模型，我可以在数据库中使用同一个表，因为字段本身不需要更改，只需通过 has_many、belongs_to 等指定行为。请记住，有很多不同的选项，因此模型的数量非常大。

首先，出于可读性目的，我认为在测试本身旁边/中定义模型并不是一个坏习惯（如果我有多个使用相同模型的测试，那么我会将它们组合在一起并使用之前方法）。所以这是我的目标之一，如果您不同意，可以对此发表评论。

我不确定的第二件事是我想在所有测试中保持模型的简单/相同名称，例如“Task”，而不是 TaskWithManySubtasksAndForeignKey 或类似的丑陋的东西。问题是模型太多了，很难想出有意义和简单的名字。我不太确定这一点 - 使用相同的名称，因为它是一个常数，有点问题。我有一个代理类的解决方案，但我认为这不是最佳解决方案。我正在考虑使用像“taskModel”这样的变量（使用 let 方法），但它看起来有点冗长和不寻常。

想到的另一种选择，但我不确定是否可以轻松完成，是删除现有关联，然后定义一个新关联。所以例如添加一个has_many然后删除它，添加一个habtm ...

你会怎么做呢？

4

1 回答 1

1

在规范文件中定义独特的模型不一定是一个坏主意，因为它可以很容易地看到每个模型是如何定义的。这种方法的明显问题是如果您想在其他测试文件中重用模型。Rails 的方法是在单独的文件中定义所有模型，然后在需要它的测试中使用它们。

我认为这真的取决于你有多少模型以及你想要重用多少。在我的一个 gem 中，我采用了在 spec 文件中定义模型的方法，在另一个 gem 中，我在spec helper中定义了它们，而在另一个 gem 中，我采用了 Rails 方法并为它们使用了一个单独的目录。如果你问我更喜欢哪一个，我可能会选择包含模型的规范，因为它都在一个地方。绝对是一个主观问题。

我有时采取的另一种方法是创建一个匿名类，保证只在该测试的生命周期内存在：

describe 'my test' do
  let(:my_class) do
    Class.new(Task) do
      has_many :things
      belongs_to :something_else
    end
  end

  it 'should have many things' do
    my_class.should have(100).things
  end
end
于 2012-09-07T01:21:34.650 回答