Adding rspec tests when adding Rails 4 fragment caching?

Testing
1

I just converted my client’s site to use Rails 4, and then added fragment caching. It’s simply awesome in terms of ease and effectiveness. The migration was relatively painless due to having a very large suite of unit tests before I started.

I’d like to get input from the other members in terms of how much effort they put into adding automated tests when adding fragment caching to views.

Is it worth the client’s money?
Is manual testing good enough?
What’s the most effective technique for testing caching? Maybe Capybara integration tests? Other options?
In terms of the flow, I’d imagine maybe Capybara tests that go like this:

  1. Turn caching on for the test
  2. Clear the cache
  3. Visit the page that will be cached
  4. (Maybe) confirm that page was added to cache
  5. (Mabye) revisit page and confirm cache was used
  6. Take action that breaks the cache, either by direct api access or via Capybara UI interaction
  7. Revisit page that will have had cache busted and confirm that the page displays the correct, new information

Thoughts?

Cheers,

Justin

2

I’d say that we generally do not add coverage for fragment caching, as it’s difficult to test and not really prone to error.

Also, its sort of an implementation deal which is below the level of your integration specs.

3

Reviving this because I ran into the same question except I’ve actually got behavior to worry about.

In a nutshell, I’ve got 5 types of slides in a slideshow. One type I can’t cache, the other four I can. So I have

   cache_unless [condition], @slide

feels weird I didnt drive out that logic with specs.

Any thoughts?

4

@johnpaulashenfelter you could extract the conditional to the model (or perhaps a decorator), then test the behaviour that way, e.g. verify the result of @slide.cacheable?.