この投稿では、私がRSpecでよく使うmatcher(マッチャ)についてまとめています。
「RSpecのgitURL」
「Relish」
##1. include
includeは、expectの引数にincludeの引数が含まれていることを確認するマッチャです。
describe "スポーツ" do
it "スポーツに野球が含まれている" do
expect(["野球", "サッカー", "ラグビー", "テニス"]).to include("野球")
end
end
このテストコードを実行した場合、想定通り配列のなかに野球は含まれているため、テストは成功します。
##2. eq
eqは、expectの引数とeqの引数が等しいことを確認するマッチャです。
describe "足し算" do
it "1 + 1の計算結果は2と等しい" do
expect(1 + 1).to eq(2) # 1 + 1 = 2 =>正しい
end
end
このテストコードを実行した場合、想定通り1 + 1は2と等しいため、テストは成功します。
##3. be_valid
be_validは、バリデーション実行時の返り値がtrueであることを確かめるマッチャです。
# バリデーションでuserのnicknameは最大５文字まで
it "nicknameは5文字以下であれば登録できる" do
user.nickname = "あいうえお" # nicknameを上書きする
expect(user).to be_valid # be_validでuserが登録できるか判定
end
このテストコードを実行した場合、想定通りnicknameは5文字以下のため、テストは成功します。
##4. have_content
expect(page).to have_content('X')
訪れたpageの中に、Xという文字列があるかどうかを判断するマッチャです。
pageは訪れた先のページの見える分だけの情報が格納されています。例えば、ページに「ログイン」と書かれたボタンがある場合、「ログイン」という文字列情報がpageに格納されています。
ただし、カーソルを合わせてはじめて見ることができる文字列はpageの中に含まれません。
# ログインページに「ログインボタン」があることを確認する
expect(page).to have_content('ログイン')
また、have_contentの逆で、文字列が存在しないことを確かめるhave_no_contentマッチャがあります。
##5. have_link
expect("要素").to have_link 'ボタンの文字列', href: "リンク先のパス"
要素の中に当てはまるリンクがあることを確認するマッチャです。また、have_linkはa要素に対して用います。
# ログインページにログイン処理を行うパスが存在する
expect(page).to have_link 'ログイン', href: new_user_session_path # このコードでは要素でなくpageを用いています。
また、have_linkの逆で、当てはまるリンクがないことを確認するhave_no_linkマッチャがあります。
expect("要素").to have_no_link 'ボタンの文字列', href: "リンク先のパス"とすることで、要素の中に当てはまるリンクがないことを確認できます。
##6. change
expect{ "何らかの動作" }.to change { "数が変化するもの" }.by(X)
数がいくつ(X)変化するのかを確認するマッチャです。
# pageにある「投稿する」ボタンをclick_onメソッドでクリック
expect{ click_on "投稿する" }.to change { Tweet.count }.by(1) # Tweetモデルのレコードのカウントが１つ上がる
# 変数aに対して、いくつ変化するか確認
expect { a += 1 }.to change { a }.by(1) # 値の増減を、相対値で検証
# => a = 2
expect { a += 3 }.to change { a }.from(2).to(5) # 状態が何から何に変わったのかを検証
# => a = 5 (aが2から5に変化)
##まとめ
今回紹介したRSpecのマッチャはは、ごく一部で勉強する中でまだまだ多くのマッチャが存在することを知りました。
今後も、新しい気付きや学んだことを投稿していきたいと思います。何か誤り等あれば、コメントにて教えてください。