将 Bullet Gem 与 RSpec 一起使用的有效方法是什么？现在我觉得如果我将它与我当前的单元测试框架一起使用，我会收到很多通知或测试失败，因为测试本身中的 n+1 个查询与我的生产应用程序中发生的事情无关，例如检查值或关联。因此，修复 n+1 故障不需要在我的 Controller 或模型上设置任何东西，而是需要在我的测试设置中设置一些东西以不抛出该特定错误，而且我没有看到我的应用程序有真正的性能改进。
最佳答案
最有效的方法是根本不用。在测试中减少 n+1 查询可能有一些合法的优势，最明显的是加快整体执行时间。然而，您很可能是 testing too much或获得的 yield 不如what is possible .我通常还发现编写额外的代码来帮助支持测试而不是为应用程序的整体值(value)做出贡献是没有吸引力的。
请允许我建议您的时间的替代用途。仅对您舒适水平的绝对最低限度进行单元测试。我个人喜欢关注涉及验证相关问题和金钱或其他数学的复杂方法，您可能有不同的优先级。划清界线将腾出一大堆时间来编写测试套件中最无用和最脆弱的部分，这将占据您维护预算的大部分。
现在，你所有的额外时间都用来做什么？别担心，我们会为您找到一些事情要做...您可以从编写一些验收测试开始，特别是对于使用您刚刚放弃了一大堆单元测试的对象的区域。现在，您的 n+1 警告实际上来自用户点击页面时的同一位置。现在您可以继续删除所有 n+1 个查询。
但是等等!也不要那样做。相反，花更少的时间 setting up your relationships to use the touch option .然后，当子对象更新时，父对象也将更新。这与 n+1 查询到底有什么关系，您可能想知道。看起来我们只是在添加查询...
这就是 Russian doll caching 的位置进来。添加它并正确测试它，将消耗释放的单元测试和 n+1 消除时间(如果你不小心的话，然后是一些)。好处是它更“真实”，对模型中无关紧要或不相关的实现更改更有弹性，并且对应用程序的性能有了巨大的提升，远远超过通过急切加载所有内容来消除每个 n+1 查询的效果前面可能已经提供了。您将希望尽可能多地移动到嵌套缓存中并尽可能地延迟加载所有内容，以充分利用此方法。
n+1 万岁!
关于ruby-on-rails - 使用 Bullet 和 RSpec gem 减少 n+1 查询，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26247288/