我们应该在Rails工厂中使用Faker吗？
我喜欢Faker ，我在我的seeds.rb使用它seeds.rb一直用真实的数据来填充我的开发环境。
我也刚刚开始使用Factory Girl ，这也节省了大量时间 – 但是当我在网络上搜索代码示例时，我没有看到很多人将两者结合起来的证据。
问：为什么人们不在工厂里使用faker有充分的理由吗？
我的感觉是，通过这样做，我会通过随机播种随机 – 但可预测的 – 数据来增加我的测试的稳健性，这有望增加错误弹出的可能性。
但也许这是不正确的，或者对硬编码工厂没有任何好处，或者我没有看到潜在的陷阱。 是否应该或不应该合并这两颗gem有充分的理由吗？
有些人反对它，就像这里一样 。
不要使用随机属性值
一种常见的模式是使用假数据库（如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所做的那样，随机值可以帮助你发现错误。 虽然可能，但这显然意味着你有一个更大的问题：测试套件中的漏洞。 在最糟糕的情况下，这个bug仍未被发现; 在最好的情况下，您会收到一条神秘的错误消息，在下次运行测试时会消失，这使得调试变得困难。 确实，一个神秘的错误总比没有错误好，但随机工厂仍然不适合替代正确的unit testing，代码审查和TDD来防止这些问题。
因此，随机工厂不仅不值得努力，甚至会让你对你的测试产生错误的信心，这比没有测试更糟糕。
但是如果你愿意的话，没有什么可以阻止你去做，就这样做。
哦，并且有一种更简单的方法可以在最近的FactoryGirl中内联一个序列，该引用是为旧版本编写的。
由你决定。
在我看来，在测试中随机数据是一个非常好的主意，它总是帮助我发现我没有想到的错误和角落情况。
我从不后悔随机数据。 @jrochkind描述的所有要点都是正确的（你应该在阅读之前阅读另一个答案），但你也可以（并且应该）在spec_helper.rb写出这spec_helper.rb
config.before(:all) { Faker::Config.random = Random.new(config.seed) }
这将使您可以使用可重复的数据进行可重复的测试。 如果您不这样做，那么您将遇到另一个答案中描述的所有问题。
我喜欢使用Faker，通常在使用更大的代码库时这样做。 使用Faker with Factory Girl时，我发现以下优点和缺点：
可能的缺点：
- 更难以重现完全相同的测试场景（至少RSpec通过每次显示随机数生成器种子并允许您使用它重现完全相同的测试来解决此问题）
- 生成数据会浪费一些性能
可能的优点：
- 使数据显示通常更易于理解。 在手动创建测试数据时，人们倾向于采用各种捷径来避免繁琐。
- 同时使用Faker为测试构建工厂为您提供了为演示生成漂亮演示数据的方法。
- 在运行测试时，您可以随机发现边缘案例错误