【技術書メモ3】everyday Rails RSpecによるRailsテスト入門
- イントロダクション
- RSpecのセットアップ
- モデルスペック
- 意味のあるテストデータの作成
- フィーチャスペックでUIをテストする
- リクエストスペックでAPIをテストする
- スペックをDRYに保つ
- 速くテストを書き、早いテストを書く
- 最後のアドバイス
イントロダクション
・テストは信頼できるものであること
・テストは簡単に書けること
・テストは簡単に理解できること
RSpecのセットアップ
spec 作成したスペックファイルを格納するディレクトリ
spec/spec_helper.rb
・RSpecの出力をドキュメント形式に変更する
.rspecに
--equirespec_helper
--formatdocumentation
モデルスペック
・有効な属性で初期化された場合は、モデルの状態が有効（valid）になっていること
・バリデーションを失敗させるデータであれば、モデルの状態が有効になっていなこと
・クラスメソッドとインスタンスメソッドが期待通りに動作すること
一時的にバリデーションをコメントアウトしたり、テストを書き換えたりして、結果が変わることを確認する。
・期待する結果は能動的で明示的に記述すること
・起きてほしいことと、起きて欲しくないことをテストすること
・境界値テストをすること
・可読性を上げるためにスペックを整理すること
意味のあるテストデータの作成
FactoryBot
FactoryBot.buildを使うと新しいテストオブジェクトをメモリ内に保存FactoryBot.createを使うとアプリケーションのテスト用データベースにオブジェクトを永続化
ファクトリ内の重複をなくす
・ファクトリの継承
・トレイト（trait）
フィーチャスペックでUIをテストする
・モデルとコントローラが他のモデルとコントローラと上手く一緒に動作することを確認する。
・Capybaaを使うとリンクをクリックできたり、Webフォームを入力したり、画面の表示を検証したりできる。
・click_buttonを使うと、起動されたアクションが完了する前に次の処理へ移ってしまうことがあるので、cliclk_buttonを実行したexpect{}の内部で最低でも1個以上のエクス白テーションを実行する。
・save_and_open_pageをテストが失敗する場所の直前に挟み込むと、なぜテストが失敗したのかブラウザ上で詳しくわかる。
リクエストスペックでAPIをテストする
スペックをDRYに保つ
統合テストでaggregate_failuresを使えば、同じコードを何度も実行して遅くなったり、複雑なセットアップを複数のテストで共有したりせずに、テストが失敗した複数のポイントを把握することができる。
速くテストを書き、早いテストを書く
focusというタグをつけるだけで、focusタグを持つスペックだけを実行することができる。
また、bin/rspectag~slowとテストを実行すれば、タグがついたテスト以外を実行することができる。
※タグはコミットの前に必ず削除する
最後のアドバイス
小さなテストで練習！
自分がやっていることを意識！
短いスパイクを書くのはOK！
小さくコードを書き、小さくテストするのもOK！
統合スペックから書く！
テストをする時間を作る！
常にシンプルに！
古い習慣に戻らない！
テストを使ってコードを改善！
練習し続ける！
