まえがき
自身のRailsの理解度としては、X(旧Twitter)の大まかな機能についてクローンアプリを作成したことはあるが、RSpecなどのテストフレームワークは導入程度の知識しかない状態です。
まさに、本書が定める対象であるRailsの開発経験は多少あるものの、テストにはまだ馴染めていない開発者
にあたるかと思います。
良い点
- 複数種のSpecが存在するが、スムーズに導入していける順序で解説されている
-
ざっくりと
- モデルスペック=単体テスト
- コントローラスペック、リクエストスペック=機能テスト
- システムスペック=統合テスト
のように自分は解釈し、実際にシステムを作っていく際の流れに乗っているように思いました
-
- ただし、上記については既存アプリへの導入のケースを指しており、TDDにおいては逆順となることも触れられている
- サンプルアプリが用意されており、自身のアプリケーションが無くとも手を動かしながら学べる
- 作成したアプリケーションもありましたが、まずはサンプルで手を動かし、その後自身のアプリでもテストケースを作成するという流れで学習を行いました
- おおよそ、学習のためなどに作成するアプリケーションで行うテストを網羅している
- メール送信やファイルアップロード、外部のWebサービス呼び出しなど
悪い点
といっても特に思い当たらないので、自身のアプリに導入する際、躓いた点を記述しておこうと思います。
- Capybaraを使ったテストケースを作成する際、docker + chromeの環境をm2 Macへ作成する
- hotwireを使用し、
turbo_stream
を使っている場合にはjs: true
かつ、リクエストの際にヘッダーへ明示的にturbo_stream
リクエストであることを記述する必要がある
重要な考え方だと学んだ点
- テストは、自身の書いたプログラムに自信、裏付けを得るために書くべき
- 可読性を犠牲にしてまで、DRYにする必要はない
- バリデーションは書き忘れやすいが、テストを書きながらであれば抜けにくい
- テストがないよりは、遅いテストでもない状態よりはずっと良い(0 → 1がまず大切で、テストを書くことへのハードルを下げている)
- コントローラのテストは退屈であるべき
- 不要だと明確になった時点で、そのテストは削除するべき
- テストが遅い時、並列実行に頼るだけでなく、その他の要因も検討すること
- マッチャが持つオプションなどを調べることで簡潔に解決し、テストコードの短縮が可能であるケースも多々ありそうなので、使用するマッチャのドキュメントを読むことも大切であること
まとめ
記事を書く時点で、本書の提供するサンプルアプリへの導入、自身のツイッタークローンアプリへの導入を行って記述しています。
既存アプリへの導入なので、中から外(モデルスペックからシステムスペックの向き)で書いていくのが効率的なようですが、あえてシステムスペックから着手してみました。
大きく困ることはありませんでしたが、既にモデルの持つべき挙動や制約が決まっている状況からテストケースを書くのであれば、モデルスペックから記述していった方が、より外のテストで異常系を記述する際に機械的に作成していけるのかと感じました。
ここまで読んでいただき、ありがとうございました!