sugulogの日記

Rials、RSpec!様々なテストを記述してみよう!!

f:id:sugulog:20201114010709p:plain
こんにちは、すぐるです!

sugulogをお読みいただきありがとうございます!!

このブログは、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準に書いています。

少しでもお役に立てれば幸いです。

 

今回は、RailsRSpecということで

  • 様々なテスト方法

について簡単に解説します!!

その為このブログを読むことで、テストについてより理解が深まるのはもちろん、テスト時のカンニングペーパーとしても役に立ちます。

是非最後までご愛読ください。

 

またRSpecで行うテストの基礎知識に関しては、以下のブログで解説しています!

sugulog.hatenadiary.jp

sugulog.hatenadiary.jp

では早速、みていきましょう!!

・ 前提条件

テストを行うにあたって、テスト環境で以下のgemを導入しています。

f:id:sugulog:20201111164413p:plain

またrails g respec:installやspecファイルの作成、FactoryBotを省略するための記述等々は済んでいるものとします。

そして実際のテストするアプリケーションには、対象となるバリデーションの設定も定義されているとします。

※テストの記述は基本的にexampleの箇所のみ解説します。

・userのnicknameが空では登録できないことを確かめるテスト

f:id:sugulog:20201111170520p:plain

2行目ではbuildメソッドでfactory_botの値を取得しnicknameの値を空に上書きしています。

3行目では2行目の値がバリデーションにより保存できない状態であるかを真偽値で確かめています。

そして4行目ではerrorsメソッドの引数で対象のカラムを指定し、保存できなかった場合のエラー内容を取得しています。

またincludeマッチャでそのエラー内容にcan’t be blankが含まれているかを確かめています。

can’t be blankは元々RailsのGemで用意されているエラーメッセージのことで、空白にすることはできないというエラー内容を表しています。

この記述を元にすれば、様々なパターンの空では保存できない場合のテストが記述できそうですね!!

・userのnickname、email、password、password_confirmation(確認用パスワード)が全て存在すれば登録できるを確かめるテスト

f:id:sugulog:20201111173417p:plain

2行目ではbuildメソッドでfactory_botの値を取得しています。

3行目ではbe_validでexpectの引数にしたインスタンスが全てのバリデーションをクリアする場合パスするを確かめています。

factory_botでテストする値さえ定義されていれば簡単に行えそうですね!!

・passwordが存在してもpasseord_confirmationが空では登録できないことを確かめるテスト

f:id:sugulog:20201111174740p:plain

 2行目ではbuildメソッドでfactory_botの値を取得しpassword_confirmationの値を空に上書きしています。

3行目では2行目の値がバリデーションにより保存できない状態であるかを真偽値で確かめています。

そして4行目ではerrorsメソッドの引数で対象のカラムを指定し、保存できなかった場合のエラー内容を取得しています。

またincludeマッチャでそのエラー内容にdoesnt't match Passwordが含まれているかを確かめています。

doesn't match Passwordはパスワードが一致しないというエラー内容を表しています。

・nicknameが7文字以上では登録できないことを確かめるテスト

f:id:sugulog:20201111175533p:plain

 2行目ではbuildメソッドでfactory_botの値を取得しnicknameの値を7文字に上書きしています。

3行目では2行目の値がバリデーションにより保存できない状態であるかを真偽値で確かめています。

そして4行目ではerrorsメソッドの引数で対象のカラムを指定し、保存できなかった場合のエラー内容を取得しています。

またincludeマッチャでそのエラー内容にis too long (maximum is 6 characters)が含まれているかを確かめています。

is too long (maximum is 6 characters)文字数が多いよ(多くても6文字以下にしてね)というエラー内容を表しています。

nicknameの値とエラー内容の数字を変えれば様々な文字数に対応できそうですね!!

・passwordが5文字以下では登録できないことを確かめるテスト

f:id:sugulog:20201111181338p:plain

 2行目ではbuildメソッドでfactory_botの値を取得しpasswordの値とpassword_confirmationの値を5文字に上書きしています。

passwordはpassword_confirmationと値が一致しないといけないので、buildの際に2つとも同じ値に上書きしています。 

3行目では2行目の値がバリデーションにより保存できない状態であるかを真偽値で確かめています。

そして4行目ではerrorsメソッドの引数で対象のカラムを指定し、保存できなかった場合のエラー内容を取得しています。

またincludeマッチャでそのエラー内容にis too short (minimum is 6 characters)が含まれているかを確かめています。

is too short (minimum is 6 characters)文字数が少ないよ(少なくても6文字以上にしてね)というエラー内容を表しています。

こちらもpasswordの値とエラー内容の数字を変えれば様々な文字数に対応できそうですね!!

・nicknameが6文字以下では登録できることを確かめるテスト

f:id:sugulog:20201111180309p:plain

 2行目ではbuildメソッドでfactory_botの値を取得しnicknameの値を6文字に上書きしています。

3行目ではbe_validでexpectの引数にしたインスタンスが全てのバリデーションをクリアする場合パスするを確かめています。

〇〇文字以上or以下なら登録できるのテストは、基本的にこの形を使えば確かめられそうですね!!

・重複したemailが存在する場合は登録できないことを確かめるテスト

f:id:sugulog:20201111181957p:plain

 2行目ではcreateメソッドでfactory_botの値を取得しuserに代入し、テスト用のデータベースに値を保存しています。

そして3行目ではbuildメソッドでfactory_botの値を取得し、emailの値をuser.email(先ほど保存した情報userのemail情報)として上書きしています。

 4行目では値がバリデーションにより保存できない状態であるかを真偽値で確かめています。

そして5行目ではerrorsメソッドの引数で対象のカラムを指定し、保存できなかった場合のエラー内容を取得しています。

またincludeマッチャでそのエラー内容にhas already been takenが含まれているかを確かめています。

has already been takenもう既にその値は受け取っているよというエラー内容を表しています。

重複のテストは基本的にこの形を使えば確かめられそうですね!!

・コントローラーのnewアクションを確かめるテスト

f:id:sugulog:20201112212320p:plain

今回はnewアクションの中身がない場合のテストを行っています。

そのためアクションが動いた後に、しっかりと指定したページに遷移するかを確かめればOKです。

2行目ではgetメソッドを指定し、newアクションを擬似的にリクエストしています。

3行目のresponseではリクエストが行われた後の遷移先のビュー情報を取得しています。

そしてrender_templateマッチャでnewアクションのリクエストされた時に遷移するビューを取得し、responseと同じビューかを確かめています。

・コントローラーのeditアクションを確かめるテスト

f:id:sugulog:20201113213423p:plain

editアクションはidを取得するため指定したページに遷移されるか以外に、アクション内で定義しているインスタンス変数が期待している値になっているかもテストする必要があります。

今回はtweetコントローラーのeditアクションのテストと仮定し、idの値を代入した@tweetを定義しているものとします。

idを取得する際にはまずデータが保存されている必要があります。

そのためcreateでデータをテスト用データベースに保存し、tweetに代入しています。

次にgetメソッドを使い擬似的にアクションをリクエストしています。

その際ですがparamsでtweetのidを取得しています。

後はassignsメソッドでインスタンス変数を取得し、その値がcreateで保存したtweetと同じ値かを確かめています。

2つ目のexampleではアクションが動いた後に、しっかりと指定したページに遷移するかを確かめています。

ただiこちらもidが必要なので、1つ目のexampleと同じ方法で取得しています。

・コントローラーのindexアクションを確かめるテスト

f:id:sugulog:20201113222009p:plain

indexアクションではtweetコントローラーで全てのレコードの値を代入した@tweetを定義しているものとします。

またcreated_atを利用し降順に表示されるように定義されているものとします。

ここでのポイントはその取得されるレコードは配列の形で取得されるということです。

そのためcreate_listを使用し、tweetの内容を3つ複製してtweetsに代入しています。

そしてgetメソッドで擬似的にアクションをリクエストしています。

後はassignsメソッドでインスタンス変数を取得し、その値がcreate_listを代入したtweetsと同じ値かをmatchマッチャを使い確かめています。

また実際に表示させる際は、created_atを利用し降順に表示しています。

そのためsortメソッドを使いテストでも降順にしています。

そして2つ目のexampleではアクションが動いた後に、しっかりと指定したページに遷移するかを確かめています。

 

以上、今回のブログでした。

テストについてより理解が深まり、テスト時のカンニングペーパーとしても役に立ちそうですか??

まだ僕自身もテストに対する知識は薄いので、これからどんどん深めていきます(≧∀≦)/

 

最後に!!

今後も、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準にブログを書いていきます。

少しでも気になった方はお試しでもいいので1度、読者登録お願いします!

またTwitterでもプログラミングに関することを中心に情報を発信してます。

宜しければそちらのフォローもお願いします。

最後までご愛読いただきありがとうございました!!