Request Specについて

#目次
①Request Specとは
②Request Specの記述の流れ
③テストの実行

##①Request Specとは
コントローラのテストコードを書くために特化したもの。(RequestSpecを導入後使用可能)
基本的なテストの内容はcontrollerテストと同様だが、requestテストではパスを指定する。
get post patch deleteメソッドを実行するとテストの対象となるルーティングが行われ、対応するコントローラーのアクションが実行される。このときresponse.statusが200出なければいけないし、response.bodyに特定の文字列が含まれることをテストできる。

##②Request Specの記述の流れ

spec/requests/clients_spec.rb

  describe ClientsController, type: :request do

   before do
    @Clients = FactoryBot.create(:client)
   end

   describe 'GET #index' do
   it 'indexアクションにリクエストすると正常返ってくる'
     get root_path
     expect(response.status).to eq 200
   end
   it 'リクエストに成功すると、投稿済みのメモが存在する'
     get root_path
     expect(response.body).to include(@client.memo) 
   end
   it 'リクエストに成功すると、投稿フォームが存在する'
     get root_path
     expect(response.body).to include('投稿') 
   end
  end
 end

上記のように記述をする。
get root_pathはどのように記述するかというとターミナル上でrails routesをすることでリクエストすべきパスが見つかるので、それを記述する。idが含まれる場合は get client_path(@client)などと記述する。

response.statusを実行することによって、レスポンスのステータスコードを教えてくれる。

<補足>
HTTPレスポンスステータスコードについて
①情報レスポンス(100~199)
②成功レスポンス(200~299)
③リダイレクト(300~399)
④クライエントエラー(400~499)
⑤サーバーエラー(500~599)

①情報レスポンス(100~199)
暫定レスポンスで、その時点までのすべてに問題なく、クライアントはリクエストを継続してよい、リクエストが完了している場合はレスポンスを無視していいことをしめす
②成功レスポンス(200~299)
リクエストが成功したことを示す。
③リダイレクト(300~399)
リクエストに対して複数のレスポンスがあることを示す。
④クライエントエラー(400~499)
構文が無効であるためサーバーがリクエストを理解できないことを示す
⑤サーバーエラー(500~599)
サーバー側で処理方法がわからない事態が発生したことを示す。

response.bodyを実行することによって、ブラウザに表示されるHTMLの情報を抜き出すことができるかできる。

##③テストの実行

ターミナル

 bundle exec rspec spec/ファイル名