私は通常、Fat Model、Skinny Controller アプローチを使用していますが、複雑なコントローラー アクションをテストするポイントは理解できますが、疑問に思っているのは、Rails スキャフォールディングによって生成される RESTful アクションのコントローラー テストを作成する理由はあるのでしょうか?
3 に答える
簡単に言えば、アプリケーションにコードがあり、自分で管理している場合は、そのコードをテストしてください。
InheritedResources やその他の REST gem によって提供されるアクションや動作のテストを書くことは避けていますが、ロジック、特にリダイレクトと認証/リソース所有権のロジックができたら、それをテストする必要があります。特に、最後に scaffold と rspec を使用したときにも、これらすべてのテストが生成されました。
一般に、認証と承認をテストするときに便利だと思います。この時点では、コンテンツが何を返すかはあまり気にしませんが、適切なリダイレクト、ステータス コードなどを取得すればもっと気にします。
私がコントローラーのテストを重視する 2 つ目のケースは、コントローラーが複数の方言で応答できる場合です。例: JSON、XML、および/または HTML。ただし、フォーマットが複雑になると、ビルダでこれを行い、コントローラでこの複雑さを隠さない方がよいでしょう。
私の経験から、コントローラーの仕様またはテストは、アクションのパスまたは値をデバッグするのに役立ちます。多くの場合、次のように表示されます。
@post = some_logic_gets_a_post
if @post.present?
# happy path
else
# failure path
end
コントローラー テストを使用すると、想定に基づいて正しい状態に入る、または正しい例外にヒットすることを確認できます。