我们应该在 Rails Factory 中使用 Faker 吗？

I love Faker https://github.com/stympy/faker，我在我的seeds.rb一直用真实的数据填充我的开发环境。

我也刚刚开始使用工厂女工 https://github.com/thoughtbot/factory_girl_rails这也节省了大量时间——但是当我在网上寻找代码示例时，我没有看到太多人们将两者结合起来的证据。

问：人们不在工厂中使用 faker 有充分的理由吗？

我的感觉是，通过这样做，我可以通过每次播种随机但可预测的数据来提高测试的稳健性，这有望增加出现错误的机会。

但也许这是不正确的，与对工厂进行硬编码相比没有任何好处，或者我没有看到潜在的陷阱。这两种宝石应该或不应该结合在一起有充分的理由吗？

有些人反对它，因为here http://arjanvandergaag.nl/blog/factory_girl_tips.html.

不要使用随机属性值

一种常见的模式是使用假数据库（如 Faker 或 Forgery）来生成随机值 苍蝇。这对于姓名、电子邮件地址或 电话号码，但它没有任何实际用途。创造独特 值对于序列来说非常简单：

FactoryGirl.define do   
  sequence(:title) { |n| "Example title #{n}" }

  factory :post do
    title
  end 
end

FactoryGirl.create(:post).title # => 'Example title 1' 

您的随机化 数据可能在某个阶段触发测试中的意外结果， 让您的工厂难以合作。任何可能的值 以某种方式影响你的测试结果必须被覆盖， 意义：

随着时间的推移，您会发​​现新的属性，使您的测试 有时会失败。这是一个令人沮丧的过程，因为测试可能会失败 每十次或每百次运行仅一次 - 取决于运行次数 有哪些属性和可能的​​值，以及哪种组合 触发该错误。您必须列出每个此类随机属性 每个测试都覆盖它，这是愚蠢的。所以，你创建非随机的 工厂，从而否定了原始随机性的任何好处。 有人可能会争辩说，就像 Henrik Nyh 那样，随机值可以帮助你 发现错误。虽然有可能，但这显然意味着你有更大的 问题：你的测试套件中存在漏洞。在最坏的情况下，该错误 仍然未被发现；在最好的情况下，你会得到一个神秘的 错误消息在您下次运行测试时消失，使得 很难调试。确实，一个隐秘的错误比没有错误要好，但是 随机工厂仍然不能替代适当的单元测试， 代码审查和 TDD 可以防止这些问题。

因此，随机工厂不仅不值得付出努力，而且 甚至让你对自己的测试产生错误的信心，这比 根本没有测试。

但只要你愿意，没有什么可以阻止你去做，就去做吧。

哦，在最近的 FactoryGirl 中有一种更简单的方法来内联序列，该引用是为旧版本编写的。