自分用のアウトプット。
context
describeでどのような機能を確認するのかに対して、contextはどのような状況を確認したいのかを記述する。
context ‘新規登録がうまくいく時’ do
it ‘nicknameが6文字以下で登録できる’ do
# ここにコードを記述
end
end のように記述する。
be_valid
expectのインスタンスが正しく保存されるかどうかを判断する。
expect(インスタンス).to be_valid のように記述。
FactoryBotの記述（tweet.rb）
association :user ←Tweetは必ずUserに紐付いているのでこう記述。逆にUserは必ずTweetを持っているわけではないので、user.rbには記述しない。
コントローラーのテストコードでは、リクエストとレスポンスに着目する。
RequestSpec
コントローラーのテストコードを書くために特化した手法。
indexアクションにリクエストした時の挙動を確認するためには
get root_path と記述。
response
リクエストに対するレスポンスそのものが含まれる。
HTTPステータスコード
HTTP通信において、どのような処理の結果となったのかを示す。
100〜 処理の継続中
200〜 処理の成功
300〜 リダイレクト
400〜 クライアントのエラー
500〜 サーバーのエラー
binding.pryと組み合わせて、処理の止まったところで
response.status と入力すると結果が返ってくる。
response.body
ブラウザに表示されるHTMLの情報を抜き出す
expect(response.body).to include @tweet.text
↑ブラウザで表示される内容に、Tweetの投稿文が含まれているかどうか
結合テストコードの書き方
SystemSpec
結合テストコードを記述するための仕組み。
Capybara
SystemSpecを記述するために必要なGem。Gemfileに標準で記載されている。
visit
visit ◯◯_path と記述すると、◯◯のページへ遷移することを表現。
page
visitで訪れた先のページの見える分だけの情報が格納されている。
have_content（マッチャ）
指定する内容が含まれているかどうかを判断する。
fill_in
フォームへの入力を行うことができる。
find().click
()内にクリックしたい要素を入れる。
change（マッチャ）
何かしらの動作をして、モデルのカウントをする時などに使用。
expect{“ある動作”}.to change {モデル名.count}.by(1)
↑ある動作を行って、モデルのレコードが1つ増えることを確認
current_path
現在いるページのパスを示す。
hover
特定の要素にカーソルを合わせたときの動作を表現できる。
have_no_content（マッチャ）
存在しないことを確認する。
テストコードの練習中。
練習問題をひーひー言いながら解いてます。
意味は分かるんだけど、しっかり自分で書けるようにならないと。
練習練習練習。
