*この記事はRSpecのバージョンが3.8の時(現時点最新版)のRSpecの公式Documentationを元に作成しました。
Ruby on Railsで開発をしていく中で、どの場合にどのテストを書くべきなのか筆者の中ではっきりしなかったので、調べてみました。
#Controller specs
controller specsはRailsのFunctionalテストのためのRSpecラッパーである。
Controller specsでは、それぞれのexampleの中で一つのhttpリクエスト(GET,POST等)をシミュレーションすることを許し、そのリクエストに対して特定の結果が得られるかどうかのテスト、つまり単体のテスト（Unit test）を行う。
テストの例
- テンプレートがレンダリングされているか
- 意図したページにリダイレクトされているか
- コントローラの中でviewと共有するための変数（インスタンス変数）が意図したものになっているか
- リクエストに対するレスポンスとともに意図するCookieが送られているか
#Request specs
Request specはRailsの統合テストの周りをカバーするためのラッパーを提供するものである。
Request specはルーティングを含め全ての階層（コントローラー、モデル、ビュー等）を通してテストできるようにデザインされている。
しかし、スタブを使うことは推奨されていない。（スタブは統合テストではよく利用される）
RequestSpecではControllerSpecと同じように１つのリクエストに対してのテストもできるが、さらに複数のコントローラーを通したリクエストのテストの評価や複数のセッションを通したテストの評価も可能である。
テストの例
- 会員登録機能のテスト
#Feature specs
Feature specsは一つのアプリケーションを通し、それぞれの機能が意図した通りに動くかを確認するハイレベルなテストである。
このテストでは実際に外部インターフェイス（通常はwebページ）を通してアプリケーションが動くか確認するのが良いとされている。
Feature specsではCapybaraというGemが必要である。
CapybaraではブラウザのHTTPリクエストを通してシミュレーションすることを意図している。
ちなみにFeature specでは多くのエイリアスを用意しており、それはFeature specがCustomer tests やacceptance testsとして読めるようにしているため。
###テストの例
- あるアプリケーションのトップ画面を最初に訪れ、そこから会員登録をするまでの流れのテスト
- ecサイトで商品を買い物カートに入れて、購入するまでの流れのテスト
#####Customer testとは？
Unit testは機能をテストするために開発者によってモデリングおよびコーディングまでされるものに対して、Customer testは実務に適したテストができるようにカスタマーによって少なくともモデリングされ、またコーディングまでされる可能性の高いtestのこと。
Feature specではエンジニア以外の人が利用する可能性も考えて、様々なバックグラウンドを持つ人が理解しやすいように様々なエイリアスを持っている。
*現在、筆者が使っているspecは以上なので、今後別のspecを使うことになった場合、順次追加していきます
##参考