今回はアプリケーションテストについてお話ししていきます。
概要なので細かい記述方法やメソッドの紹介はありません。
アプリケーションの動作テスト
凄腕プログラマーでもバグを出さないことはあり得ない
テストをすることによって、事前にエラーになり得る箇所を発見し修正できたり、要件の漏れを防ぐことができる。
誰でもミスはするってことですね。少し安心。
なぜテストを行うのか
例えばアプリ上で買い物ができるアプリをテストなしでリリースしたとする。
数万人というユーザーがそのアプリをダウンロードしいざ買い物をしてみたが、決済したはずの商品がされていない、なんてことのエラーが発生した場合果たしてどれくらいの損失になるのか。
当然ユーザーからの信用も失います。
テストコード書くときの原則
大きく分けて５つあります。
- 各exampleで期待する値は一つ
- 期待する結果を分かりやすく記述
- 起きて欲しいこと、起きて欲しくないこと両方をテストする
- 境界値をテストする
- 可読性を考えつつ、適度にDRYする
また、Railsでは基本的にモデルとコントローラーのファイルに対してテストコードを作成します。
その際はRspecという独自の言語を利用します。
コントローラーのテスト
コントローラー内のメソッドであるアクションが呼ばれた際の挙動をチェックするもの。
１つのアクションにつき次の２点を確かめる。
- アクション内で定義されているインスタンス変数の値が期待したものになるか
- アクションの持つビューに正しく遷移するか
つまり、一つのアクションに対して２つ以上の it ‘ ‘ do ~ end が必要になる。
response
example内でリクエストが行われた後の遷移先のビューの情報を持つインスタンス。
render_templateマッチャ
引数で指定したアクションがリクエストされた時に自動的に遷移するビューを返す。
モデルのテスト
以下のチャットアプリのテストを例にモデルのテストを説明します。
[メッセージを保存できる場合]
- メッセージがあれば保存できる
- 画像があれば保存できる
- メッセージと画像があれば保存できる
[メッセージを保存できない場合]
- メッセージも画像も無いと保存できない
- group_idが無いと保存できない
- user_idが無いと保存できない
以上の項目に沿って一つずつコードを書いていけば、コントローラーと比べてモデルのテストは書きやすいです。
記述量はなかなか多いですが。
テストコードを書くときのポイント
- example１つにつき、結果を一つだけ期待している
- どのテストも明示的である
- 期待できる値が返ってくるときと、そうでないときを両方テストする
- FactoryBotを上手く利用して、すっきりとまとめる
- Fakerでダミーデータを作成する
- テスト内で使用する変数は、インスタンス変数として定義するのではなく、letを使用する
まとめ
実際にある現在制作中のアプリのテストのコーディングをした感想です。
「記述量がかなり多い」
DRYではなく、分かりやすい記述を意識するため必然と多くなってきます。
「コントローラーのテストが難しい」
新しいメソッドが多くでてきたり、「何でそういう記述になるの？」という部分が多くありました。
これは復習が必要ですね。
コメント