使用RSpec进行Rails片段缓存测试 [英] Rails fragment cache testing with RSpec

问题描述

我觉得这是一个没有太多文献记载的主题，至少我在这里找到有关最佳实践的麻烦。

我正在使用cache_key在视图中进行片段缓存：

 ％tbody 
-@ employees.each | employee | 
-缓存员工做
％tr [employee] 
％td = employee.name 
％td = employee.current_positions 
％td = employee.home_base 
％td = employee.job_classes 
  

现在我可以在：belongs_to边添加：touch => true的has_many关联，这将完成我需要使该片段保持最新状态的所有操作，但是对于我一生来说，我一直在努力寻找如何进行测试的方法。

拖放到：touch => true是容易和方便的，但是它将到期逻辑分布在几个地方。我很乐意拥有一个RSpec请求规范，该规范可以检查并检查其行为，这虽然变化不大，但是可以将所有缓存要求合并到一个描述预期发生的特定文件中。 / p>

我尝试过以下方法：

 需要'spec_helper'
 include AuthenticationMacros 
 
描述雇员索引缓存 
 
在
之前做Rails.cache.clear 
 ActionController :: Base.perform_caching = true 
 login_confirmed_employee 
结束
 
执行
之后ActionController :: Base.perform_caching = false 
结束
 
指定雇员缓存在修改职位分配时被清除 
指定在修改家庭基本分配时清除了雇员缓存 
 end 
  

通过Capybara的步骤进行了充实，并进行了更新，当然，我走上了正轨。但是测试以一种奇怪的方式在忽悠。我会修改规范以输出员工对象cache_key，有时cache_keys会更改，有时不会，有时规范会通过，有时不会。

好的方法？

我知道SO希望得到可以回答的问题，所以首先开始：当我的测试环境确实需要测试时，如何设置和拆除此测试以使用缓存？默认没有缓存？但是，总的来说，我很想听听您如何成功地在应用中测试片段缓存。

编辑

我接受cailinanne的回答，因为它可以解决我明确询问的问题，但是我决定不建议进行集成测试

我没有在关联声明中指定touch，而是创建了一个特定于我的缓存需求的观察者，该观察者直接接触模型，并且我建议孤立地测试它。

我建议如果孤立地测试多模型观察者，还包括一个检查观察者的观察模型的测试，否则您可以将其存根

导致我对此的特定答案是： https://stackoverflow.com/a/33869/717365

解决方案

首先让我说，在这个答案中，您可能会比事实更同情。我一直在努力解决这些相同的问题。虽然我可以为特定测试获得可重复的结果，但我发现结果会根据我是否运行一个规格与多个规格以及是否在孢子内而有所不同。

最后，我发现，如果仅在test.rb文件中启用缓存，我的问题就会消失99.9％。听起来可能很奇怪，但是经过一番思考之后，对于我的应用程序来说这是正确的。我的大部分测试不是在视图/请求层进行的，而是不是，对于少数几个，在与用户查看相同的配置下进行测试是否有意义？

我在为此苦苦挣扎时，写了一个博客文章，其中包含一些有用的测试助手，用于测试缓存。您可能会发现它很有用。

I feel like this is a not-so-much documented topic, at least I've had a lot of trouble finding our about the best practices here.

I'm fragment caching in the view using a cache_key:

%tbody
  - @employees.each do |employee|
    - cache employee do
      %tr[employee]
        %td= employee.name
        %td= employee.current_positions
        %td= employee.home_base
        %td= employee.job_classes

Now I can add :touch => true on the :belongs_to side of my has_many associations and this will do everything I need to keep this fragment caching up to date, but for the life of me I'm having a hard time figuring out how to test this.

Dropping in :touch => true is easy and convenient but it spreads the expiry logic around a couple places. I'd love to have an RSpec request spec that walks through and checks the behavior on this, something that isn't liable to change much but can bring all the caching requirements into one specific file that describes what is supposed to be occurring.

I tried along these lines:

require 'spec_helper'
include AuthenticationMacros

describe "Employee index caching" do

  before do
    Rails.cache.clear
    ActionController::Base.perform_caching = true
    login_confirmed_employee
  end

  after do
    ActionController::Base.perform_caching = false
  end

  specify "the employee cache is cleared when position assignments are modified"
  specify "the employee cache is cleared when home base assignments are modified"
end

The specs were fleshed out with the Capybara steps of going through and making the updates of course, and I thought I was quite on the right track. But the tests were flickering in weird ways. I would modify the specs to output the employee objects cache_key, and sometimes the cache_keys would change and sometimes not, sometimes the specs would pass and sometimes not.

Is this even a good approach?

I know SO wants questions that are answerable, so to start: how can I set up and tear down this test to use caching, when my test env does not have caching on by default? In general, however, I'd really like to hear how you might be successfully testing fragment caching in your apps if you have had success with this.

EDIT

I'm accepting cailinanne's answer as it addresses the problem that I specifically ask about, but I have decided however that I don't even recommend integration testing caching if you can get away from it.

Instead of specifying touch in my association declarations, I've created an observer specific to my caching needs that touches models directly, and am testing it in isolation.

I'd recommend if testing a mulit-model observer in isolation to also include a test to check the observers observed_models, otherwise you can stub out too much of reality.

The particular answer that lead me to this is here: https://stackoverflow.com/a/33869/717365

解决方案

Let me first say that in this answer, you may get more sympathy then fact. I've been struggling with these same issues. While I was able to get reproducible results for a particular test, I found that the results varied according to whether or not I ran one versus multiple specs, and within or without spork. Sigh.

In the end, I found that 99.9% of my issues disappeared if I simply enabled caching in my test.rb file. That might sound odd, but after some thought it was "correct" for my application. The great majority of my tests are not at the view/request layer, and for the few that are, doesn't it make sense to test under the same configurations that the user views?

While I was wrestling with this, I wrote a blog post that contains some useful test helpers for testing caching. You might find it useful.

这篇关于使用RSpec进行Rails片段缓存测试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！