CODEWITHSUNDEEP
ruby-on-railsruby-on-rails-3httphttp-response-codes
Matheus Moreira
Matheus Moreira

Reputation: 17020

RSpec testing in Rails and 304 HTTP status code

Using Devise for authentication. On a controller that has:

before_filter authenticate_user!, :except => [ :index, :show ]

I always get 304 Not Modified status code instead of 200 OK on the authenticated actions, even in the browser while signed in. The views render and work just fine.

It's stopping my tests from passing:

describe 'GET index' do
  it 'should be successful' do
    get 'index'
    response.should be_success  # Fails due to 304 status code
  end
end

I thought it was my controller's fault at first, but besides the before_filter and decent_exposure, the controller couldn't be any more common.

What could possibly be the root of this issue?

Upvotes: 2

Views: 2591

Answers (2)

Matheus Moreira
Matheus Moreira

Reputation: 17020

The tests were failing because I was using Devise for authentication with the confirmable module and was not using confirmed users.

After setting the confirmed_at attribute in the factory, all tests passed.

Upvotes: 1

DigitalZebra
DigitalZebra

Reputation: 41483

304s are a good thing. In this case, it is what is expected (and desired) even though it may be giving some of your tests trouble. A 304 means that your webserver and client are communicating in a way to allow caching of the webserver's response.

I'm not entirely familiar with Rails, but I'd suspect there is a built in mechanism which is caching your responses. Here is a Rails article on caching:
http://guides.rubyonrails.org/caching_with_rails.html

And here is what looks like a way to disable caching on the Controller/Action level (ignore the parts about iframes... also this might not be the best way):
http://arjunghosh.wordpress.com/2008/04/29/how-to-force-the-browser-to-not-cache-in-rails/

Upvotes: 2

Related Questions