rspec users - Jul 2011 - Caching in Rails by Default

So, maybe I need to go to the rails list with this, but I hit my error while
testing so I figured I''d ask here first.

Basically, Rails.cache.fetch is being persisted by default in my rails
project between rspec runs.  I''ve illustrated what I''m
observing here:

https://github.com/softwaregravy/rspec-troubleshoot/commit/c63b4b09fa6e70c2312e0aa2f7ba0ce078322ccc

Furthermore, if you run that once, and then take out the test that
doesn''t
raise the error, its still in the cache.

So, to get at the ''issue'' I''m describing
specifically.  If you first run
''rspec spec/controllers/application_controller_spec.rb'' with
the following:
https://github.com/softwaregravy/rspec-troubleshoot/blob/0e22ce887cde602e49dc9bf7fa25406882b038f0/spec/controllers/application_controller_spec.rb
you seed the cache.  And then run it again without the happy case:
https://github.com/softwaregravy/rspec-troubleshoot/blob/1e36222e64bfd9c473be06fba0a5fa102d4bf0f6/spec/controllers/application_controller_spec.rb

You continue to get the failing test because the results of that block are
cached.

Now, I''m not that familiar with Rails caching.  But it appears that
there
might be an issue in which Rails is not respecting the perform_caching flag.
If that''s not the root cause, then it seems to be that rspec could be
doing
a Rails.cache.clear and/or overriding a memory cache to be used during
tests.

Thoughts?



*** LOCAL GEMS ***

abstract (1.0.0)
actionmailer (3.0.9, 3.0.5)
actionpack (3.0.9, 3.0.5)
activemodel (3.0.9, 3.0.5)
activerecord (3.0.9, 3.0.5)
activeresource (3.0.9, 3.0.5)
activesupport (3.0.9, 3.0.5)
arel (2.0.10)
builder (2.1.2)
bundler (1.0.15)
diff-lcs (1.1.2)
erubis (2.6.6)
i18n (0.6.0, 0.5.0)
mail (2.2.19)
mime-types (1.16)
polyglot (0.3.1)
rack (1.2.3)
rack-mount (0.6.14)
rack-test (0.5.7)
rails (3.0.9, 3.0.5)
railties (3.0.9, 3.0.5)
rake (0.8.7)
rdoc (3.8)
rspec (2.6.0)
rspec-core (2.6.4)
rspec-expectations (2.6.0)
rspec-mocks (2.6.0)
rspec-rails (2.6.1)
sqlite3 (1.3.3)
thor (0.14.6)
treetop (1.4.9)
tzinfo (0.3.29)

ruby-1.9.2-p180 at rspec-troubleshoot:

  system:
    uname:       "Darwin John-Hinnegans-MacBook-Pro.local 10.8.0 Darwin
Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011;
root:xnu-1504.15.3~1/RELEASE_I386 i386"
    bash:        "/bin/bash => GNU bash, version 3.2.48(1)-release
(x86_64-apple-darwin10.0)"
    zsh:         "/bin/zsh => zsh 4.3.9 (i386-apple-darwin10.0)"

  rvm:
    version:      "rvm 1.2.8 by Wayne E. Seguin (wayneeseguin at gmail.com)
[
http://rvm.beginrescueend.com/]"

  ruby:
    interpreter:  "ruby"
    version:      "1.9.2p180"
    date:         "2011-02-18"
    platform:     "x86_64-darwin10.6.0"
    patchlevel:   "2011-02-18 revision 30909"
    full_version: "ruby 1.9.2p180 (2011-02-18 revision 30909)
[x86_64-darwin10.6.0]"
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20110702/bdd13599/attachment-0001.html>

On Jul 3, 2011, at 1:08 AM, John Hinnegan wrote:
> So, maybe I need to go to the rails list with this, but I hit my error
while testing so I figured I''d ask here first.
> 
> Basically, Rails.cache.fetch is being persisted by default in my rails
project between rspec runs.  I''ve illustrated what I''m
observing here:
> 
>
https://github.com/softwaregravy/rspec-troubleshoot/commit/c63b4b09fa6e70c2312e0aa2f7ba0ce078322ccc
> 
> Furthermore, if you run that once, and then take out the test that
doesn''t raise the error, its still in the cache.
> 
> So, to get at the ''issue'' I''m describing
specifically.  If you first run ''rspec
spec/controllers/application_controller_spec.rb'' with the following:
>
https://github.com/softwaregravy/rspec-troubleshoot/blob/0e22ce887cde602e49dc9bf7fa25406882b038f0/spec/controllers/application_controller_spec.rb
> you seed the cache.  And then run it again without the happy case:
>
https://github.com/softwaregravy/rspec-troubleshoot/blob/1e36222e64bfd9c473be06fba0a5fa102d4bf0f6/spec/controllers/application_controller_spec.rb
> 
> You continue to get the failing test because the results of that block are
cached.
> 
> Now, I''m not that familiar with Rails caching.  But it appears
that there might be an issue in which Rails is not respecting the
perform_caching flag.
Looks like the perform_caching config option only impacts page caching.

See
http://pivotallabs.com/users/spierson/blog/articles/818-standup-04-30-2009-perform-caching-and-rails-cache-w3c-dtds-and-ie-range-min-max
for a brief discussion of options (that''s the first hit in a google
search for "perform_caching", btw).
> If that''s not the root cause, then it seems to be that rspec could
be doing a Rails.cache.clear and/or overriding a memory cache to be used during
tests.
You can definitely do this yourself in a global before hook, but I
don''t know how people use Rails.cache in the wild and wouldn''t
want to do anything implicit that might break existing suites.

I''d recommend using a global before hook or raising an issue in the
rails tracker.

HTH,
David

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20110703/d0cd49d1/attachment.html>