更新日: 2014年5月11日
Rails

Rails でテストをどう書くべきか備忘録

今朝聞いた今週の rebuild.fm のポッドキャストで、テストに関する話題がとても面白く勉強になりましたので備忘録メモ。全部テスト書いてたら時間が足りないし、個人的にはどの部分を重点的にテストすべきか、削っても良いのはどこかに注目して聞きました。

Rebuild: 43: Kent is More Professional (Kenn Ejima)

【お知らせ】英単語を画像イメージで楽に暗記できる辞書サイトを作りました。英語学習中の方は、ぜひご利用ください！

画像付き英語辞書 Imagict | 英単語をイメージで暗記
【開発記録】
英単語を画像イメージで暗記できる英語辞書サービスを作って公開しました

以下 rebuild.fm 話題から参考にしたいメモ

・テスト書くのは良いが、テスト原理主義、100％カバー、全部テストファーストにこだわるのは疑問。
・内部構造、実装に対するテストは書かない。
・モックは一番外側のAPI、インターフェースに対してだけ使う。（※）
・モックのためのモックとかは避ける。
・リファクタリングのためにテストを書き換えなきゃいけないようなテストは駄目。
・テストとコードを同時に変更すると、トラブルに気付きにくくなるので避ける。（※）
・テストで何を守るのか、将来それで守れるのかよく考える。
・正規表現はテストファースト。
・pry での試行錯誤をテストに残す。（※）
・予想できない外部入力に対する振る舞いをテストファーストで書くのは無理。（※）
・問題・バグがあった箇所を regression でテストに追加。（※）
・十分な自信・安心を得られる最低限のテストを書く。（※）
・テストの数を減らすため、認証・購入まわりを重点的に書き、Capybara を使うテストは少なめに。
・テストが通るのを1回確認したらコミットしない！（テスト時間短縮のため）
・UIはテストしない方が良い、UIの使い勝手はテストで書きにくい。壊したり直したりを繰り返す。
・新しい物を作りたいモチベーションが高い時は、テストファーストでなくても良いのでは。（※）
・Hello World サンプルにテストファーストは出てこない。
・動く嬉しさでプログラミングを持続できる。

（※）は特に参考にしたい項目。

感想と個人的な方針など

結構聞いていて納得できる部分が多かったです。

先に実装アイデア浮かんだ時とか、ばーっと実装コード書いて後でテスト追加とかしょっちゅうやるんですけど、まあその書き方でも良いかと確認できたのは良かった。アイデアや作りたい物が頭に浮かんだ時に、先にテスト書かなきゃと考えると自分の場合萎えます。

モックやスタブは都合の良いように取り繕えるので、できるだけ使わないようにしてる。正規表現は確かにテストファーストで書きやすいです。あと pry での試行錯誤は頻繁に行いますので、これをテストに残すのは今後取り組んでいこう。

Capybara を使うテストの場合、自分は出力させるべきデータ（サブミットされたフォーム入力データや、DB内からのユーザー名・計算した数字など）の確認を重点的にテストするようにしてます。CSSやレイアウトなどUI・デザインは変更が多いのであまりテストに含めないようにしてる。なので、デザイン・UIはテストに向かないなぁというのは実感としてあります。

認証、購入まわりなどを重点的に書くのはすでにやってるので再確認。

以上のような感じです。個人的に参考にしたい箇所以外にも、たくさん為になる話題に触れられていましたので、ぜひ rebuild.fm 聞いてみてください！WEB制作・開発に関わられる方にはとてもおすすめなポッドキャストです。

パーフェクト Ruby on Rails は、最近読んだ Rails 本の中では一番役に立った本です。Chef や Capistrano など Rails と共によく使用される技術にも触れてあります。Ruby on Rails 4 アプリケーションプログラミングは、入門的な内容で Rails の機能全体を網羅されています。

パーフェクト Ruby on Rails

Ruby on Rails 4 アプリケーションプログラミング