如何规范依赖 Memcached 的操作？
我们有一个使用 RSpec 测试的 Rails 应用程序。我们想要规范依赖 Memcached 的操作。这样做的最佳做法是什么？
我想通过存根对 Rails.cache 的所有调用来实现此目的。这是个好主意吗？
根据@Pan Thomakos的建议，我添加了一些关于我正在尝试测试的场景之一的额外细节：
我们的系统中有帐户的概念，因此在每个请求中我们都会检索当前用户和当前帐户。由于系统中的帐户不多，因此我们将它们全部保存在缓存中并从那里检索它们。
def self.find_by_slug(slug)
Rails.cache.fetch(Account.cache_key_for_slug(slug), :expires_in => 1.day) { super }
end
因此，在这种情况下，缓存不仅仅是一种很好的行为，而且是预期的行为和我想要测试的东西。因此关闭缓存是行不通的。
We have a Rails application that we test with RSpec. We want to spec operations that rely on Memcached. What is the best practice to do so?
I thought of doing this by stubbing all calls to Rails.cache. Is this a good idea?
As per @Pan Thomakos suggestion, I'm adding some additional details about one of the scenarios I'm trying to test:
We have the concept of accounts in our system, therefore on every request we retrieve the current user and the current account. Because there are not many accounts in the system, we keep them all in cache and retrieve them from there.
def self.find_by_slug(slug)
Rails.cache.fetch(Account.cache_key_for_slug(slug), :expires_in => 1.day) { super }
end
For this reason, caching in this case isn't just a nice to have behavior, but the expected behavior and the thing I want to test. Therefore turning off caching won't do.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
测试时无需存根恕我直言！
序列如下所示：
就我个人而言，我相信如果您手头有资源，那么不应该使用存根。如果您手头没有资源（即第三方服务），则应该使用存根。
存根的问题在于，如果您更改了要存根的代码，那么您将不知道它是否会损坏。
这种情况下的一个例子是，如果您从标准 memcache gem 切换到 Dahli? 或其他一些 memcache gem，它们通过返回 false、null 或其他不同值来处理缓存未命中。我的意思是真的！ Cache.set("my_key", false)! :)
切换的一个例子是离开 ASCII 协议并转向更快的二进制协议。
Memcache 是一种廉价资源，您可以使用 1 MB 内存来设置它来进行此测试。我什至可以说你可以对 mysql 做同样的事情。任何比 mysql 更大的东西，我都会开始倾向于存根，因为“设置”这些资源的成本变得很大。 YMMV。
-丹尼尔
Test without stubbing IMHO!
The sequence would look like this:
Personally, I believe if you have the resources on hand then stubbing SHOULD NOT be used. If you do not have the resources on hand (IE a 3rd party service) then stubbing SHOULD BE used.
The problem with stubbing, is that if you changed the code that you are stubbing, then you won't know if it breaks.
An example in this case would be if you switched from the standard memcache gem, to Dahli?, or some other memcache gem which handed cache misses by returning false, null or some other value differently. I mean really! Cache.set("my_key", false)! :)
A example for switching, would be to leave the ASCII protocol and move to the faster binary protocol.
Memcache is a cheap resource, you can set it up with 1 meg of ram to do this testing. I would even go as far as to say you can do the same for mysql. Anything bigger than mysql, then I would start leaning towards stubbing as the cost to "setup" those resources becomes significant. YMMV.
-daniel
如果您直接使用 Rails.cache.fetch ，那么最好的选择就是存根。但是，如果您使用控制器助手（现在位于 Rails 4 中的单独 gem 中），我遇到了这个 gem，它很有帮助 https://github.com/avit/rspec-rails-caching
It seems like if you're using Rails.cache.fetch directly your best option is to stub. But if you use the controller helpers (which are now in seperate gems in rails 4), I came across this gem which is helpful https://github.com/avit/rspec-rails-caching