2

認証にDeviseを使用する。次のようなコントローラーの場合:

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

サインインしているときでも、認証されたアクションではなく、常に304 Not Modifiedステータスコードを取得します。ビューはレンダリングされ、正常に機能します。200 OK

それは私のテストが合格するのを止めています:

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

最初はコントローラーのせいだと思っていましたが、before_filterと以外decent_exposureにコントローラーは一般的ではありませんでした。

この問題の原因は何でしょうか?

4

2 に答える 2

2

304sは良いことです。この場合、それはあなたのテストのいくつかに問題を与えているかもしれませんが、それは期待されている(そして望まれている)ものです。A304は、WebサーバーとクライアントがWebサーバーの応答のキャッシュを許可する方法で通信していることを意味します。

Railsに完全に精通しているわけではありませんが、応答をキャッシュするメカニズムが組み込まれていると思います。キャッシュに関するRailsの記事は次のとおりです。http:
//guides.rubyonrails.org/caching_with_rails.html

そして、これがコントローラー/アクションレベルでキャッシュを無効にする方法のように見えます(iframeに関する部分は無視してください...これは最善の方法ではないかもしれません):
http ://arjunghosh.wordpress.com/2008/04/ 29 / how-to-force-the-browser-to-not-cache-in-rails /

于 2011-04-17T07:25:15.697 に答える
1

確認可能なモジュールでの認証にDeviseを使用していて、確認済みのユーザーを使用していなかったため、テストは失敗していました。

ファクトリで属性を設定した後confirmed_at、すべてのテストに合格しました。

于 2011-05-10T19:36:04.367 に答える