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

查看:17
本文介绍了使用 RSpec 进行 Rails 片段缓存测试的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我觉得这是一个没有太多记录的主题,至少我在这里找到我们的最佳实践时遇到了很多麻烦.

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.

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

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

现在我可以在我的 has_many 关联的 :belongs_to 一侧添加 :touch => true ,这将完成我需要保持这个片段缓存最新的一切,但对于我的生活,我很难过想办法测试这个.

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.

放入 :touch => true 既简单又方便,但它在几个地方散布了到期逻辑.我很想有一个 RSpec 请求规范来遍历并检查它的行为,它不太可能改变太多,但可以将所有缓存要求带入一个描述应该发生的事情的特定文件中.

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.

我尝试了这些方法:

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

通过 Capybara 的步骤来充实规范,当然,我认为我走在正确的轨道上.但是测试以奇怪的方式闪烁.我会修改规范以输出员工对象 cache_key,有时 cache_keys 会改变,有时不会,有时规范会通过,有时不会.

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?

我知道 SO 想要可以回答的问题,所以开始:当我的测试环境默认没有缓存时,如何设置和拆除此测试以使用缓存?但是,总的来说,如果您已经成功,我真的很想听听您如何在应用中成功测试片段缓存.

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.

编辑

我接受 cailinanne 的回答,因为它解决了我特别询问的问题,但我已经决定,如果可以避免的话,我什至不建议集成测试缓存.

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.

我没有在关联声明中指定 touch,而是创建了一个特定于我的缓存需求的观察者,它直接接触模型,并且正在对其进行隔离测试.

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.

导致我这样做的具体答案在这里:https://stackoverflow.com/a/33869/717365

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

推荐答案

我先说,在这个回答中,你可能会得到比事实更多的同情.我一直在努力解决这些相同的问题.虽然我能够为特定测试获得可重复的结果,但我发现结果会因我是运行一个还是多个规格,以及在或不使用 spork 的情况下而有所不同.叹气.

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.

最后,我发现只要在 test.rb 文件中启用缓存,99.9% 的问题就会消失.这听起来可能很奇怪,但在一些人认为这对我的应用程序来说是正确的"之后.我的大部分测试不在在视图/请求层,对于少数在用户查看的相同配置下进行测试是否有意义?

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆