テストについて (Ruby on Rails Tutorialから)
Ruby on Rails Tutorialにおいて、どんなふうにテストを行えばよいかについての記載がありましたので、整理を兼ねてブログにしました。
この点を理解するために、テストを行う目的を確認すると、テストには次の3つのメリットがあります。
- テストが揃っていれば、機能停止に陥るような回帰バグ (Regression Bug: 以前のバグが再発したり機能の追加/変更に副作用が生じたりすること) を防止できる。
- テストが揃っていれば、コードを安全にリファクタリング (機能を変更せずにコードを改善すること) ができる。
- テストコードは、アプリケーションコードから見ればクライアントとして動作するので、アプリケーションの設計やシステムの他の部分とのインターフェイスを決めるときにも役に立つ。
上の3つのメリットは、テストを先に書かなくても得ることができますが、テスト駆動開発 (TDD) という手法をいつでも使えるようにしておけば、間違いなく多くの場面で役に立つと考えられています。
テストの手法やタイミングは、ある意味テストをどのぐらいすらすら書けるかで決まると言ってよく、たいていの開発者は、テストを書くのに慣れてくるとテストを先に書くようになるとのことです。
その他にも、アプリケーションのコードと比べてテストがどのぐらい書きにくいか、必要な機能をどのぐらい正確に把握しているか、その機能が将来廃止される可能性がどのぐらいあるかによっても異なってくるようです。
こういうときのために、
「テスト駆動」にするか「一括テスト」にするかを決める目安となるガイドラインがあると便利なので、チュートリアルでは 次のようにまとめてありました。
- アプリケーションのコードよりも明らかにテストコードの方が短くシンプルになる (=簡単に書ける) のであれば、「先に」書く
- 動作の仕様がまだ固まりきっていない場合、アプリケーションのコードを先に書き、期待する動作を「後で」書く
- セキュリティが重要な課題またはセキュリティ周りのエラーが発生した場合、テストを「先に」書く
- バグを見つけたら、そのバグを再現するテストを「先に」書き、回帰バグを防ぐ体制を整えてから修正に取りかかる
- すぐにまた変更しそうなコード (HTML構造の細部など) に対するテストは「後で」書く
- リファクタリングするときは「先に」テストを書く。特に、エラーを起こしそうなコードや止まってしまいそうなコードを集中的にテストする
上のガイドラインに従う場合、
現実には最初にコントローラやモデルのテストを書き、続いて統合テスト (モデル/ビュー/コントローラにまたがる機能テスト) を書く、ということになります。
また、不安定な要素が特に見当たらないアプリケーションや、
(主にビューが) 頻繁に改定される可能性の高いアプリケーションのコードを書くときには、思い切ってテストを省略してしまうこともあるとのことです。
尚、チュートリアルのカリキュラムにおいては、
主要なテストは、コントローラテスト、モデルテスト、統合テストの３つとなっており、３章からコントローラテスト、６章からモデルテスト、７章から統合テストとなっています。
統合テストは、ユーザーがWebブラウザでアプリケーションとやりとりする操作をシミュレートできるので特に強力で、テストにおける最も主要な武器の1つとなっています。
今後、この内容を参考に自分なりのやり方を工夫していきたいと考えております。
