はじめに
先日、ソニックガーデンでインターンをやってもらっている学生さんから、Railsのテストに関する質問を受けました。
他のRails初心者さんにとっても役立ちそうな内容だったので、こちらで共有しておきます。
質問
現在学習している「RailsによるアジャイルWebアプリケーション開発」ではscaffoldを使ってアプリを作っていきます。
rails generate scaffold xxxをした際、specディレクトリ以下に自動的にRSpecのファイルが生成されます。
たとえば以下のようなファイルです。
疑問に思ったのは、これらをベースにして、足りないところを補うといった形で開発を進めていくのが正しいやり方なのでしょうか？
それとも、これらは削除して自分が必要だと思ったところだけを記述していけば良いのでしょうか？
僕の回答
端的に答えるなら「これらは削除して自分が必要だと思ったところだけを記述」するのが正解です。
Scaffoldで生成されるのは「書き方の見本」みたいなもので、それをそのまま育てていくことは滅多にしないですね。
しかもroutingとかviewとか、実務じゃほとんど使わないテストコードも自動生成されるので、デフォルトのscaffoldは結構「お節介」ですw
まずは「なぜテストを書くのか」という理由を考えるのが大事かなと思います。
逆に「テストを書かなくてもいいのはなぜか」と考えるのもアリです。
テストを書かずにアプリケーションを作ると、次のような事態になります。
- コードを変更するたびに全部手作業と目視で動作確認する
- または「たぶん大丈夫」「きっとちゃんと動くはず」と祈りながらコードをリリースする
使い捨てのプロトタイプ的なアプリケーションや、ごく初期の小さなアプリであればこれでも問題なかったりします。
しかし、開発を進めていくとそのうち、
「今まで書いたコードを全部手作業で確認するなんて無理」
「課金処理を"たぶん大丈夫"でリリースするのはあまりにも怖い」
みたいに感じるときが出てくると思います。
そんなときに「テストを書いておく必然性」が出てきます。
テストコードを書いてテストを自動実行できるようにしておけば、上記の問題は解決できます。（テストコードでテストする内容に抜けやモレが無い限り）
おそらくぼんやりとscaffoldを作った時点では「このコードにテストは必要か？」と自問自答すると、「あった方がいいだろうけど、そんなに強く断言できるほどでもないよな・・・」という答えになることが大半だと思います。
というわけで、「scaffoldが吐いたテストコードは削除しても問題ない」という結論が出てきます。
自分で作るアプリケーションは
「このコードは手動でテストするつもりか？」
「最悪バグっても致命的な問題にならないか？」
（「すいません、すぐ直します」で許してもらえるか？）
と自問自答してみて、どちらもYESならテストを書かない、どちらかがNOなら必要なテストコードを書く、という判断基準を持つのがいいかなと思います。
これ以外にも「テストコードを書いておいた方がいい場面」はいくつかありますが、長くなるので一番基本的な判断基準だけを書いておきます。
結論：「Scaffoldに惑わされず、必要なテストコードを、必要な分だけ書く」ということで！
おわりに
このQ&Aは社内向けのyouRoomでやりとりした内容なので、僕の回答もかなり大雑把です。
また、あくまで僕の持論なので人によっては「いや、それは違う！」と思う人もいるかもしれません。
とはいえ、僕はこのポリシーに従ってRailsのテストコードを書いてきていますし、それで特に大きな問題が起きたことはありません。
なので、一つの考え方としてそれなりに意味があると思うので、このブログで紹介してみました。
以上、ご参考までに～。
Railsでテストコードについて学ぶときにはコレ！
Railsのテストの書き方がわからない、という方には電子書籍「Everyday Rails - RSpecによるRailsテスト入門」をオススメします。
単にテストコードの書き方を説明するだけでなく、テストコードに対する「考え方」も説明してあります。
あわせて読みたい
以前も別のインターン生の方からテストコードについて質問を受けたことがあります。
初心者の方にとっては「テストコードって何？それっておいしいの？？」っていう疑問がわきやすいみたいですね。
初心者でなくてもテストコードの書き方に迷っているプログラマさんは多いみたいです。
こちらの勉強会の質疑応答を読んでみると、自分が悩んでいた問題が解決するかもしれません。
