Everyday Rails - RSpec による Rails テスト入門を読んで

はじめに

Rails の RSpec をメインにした書籍はあまり多くないと考えられるので、本書の内容は Rails を軸におく開発者にとってとても有益のものだと感じた。
RSpec というテスト技法一つとってもその根底には思想があり、ベストプラクティス的な RSpec の書き方があることを知ることができた。
テストをする際の方法は必ずしも 1 つではなく、普通のコーディングと同じように様々なテストアプローチを持っておくことが効果的な RSpec を書けるようになるコツであることを学んだ。

RSpec は普通の Ruby や Rails の構文とも少し毛色が違うので、構文を覚えるのがとても大変に感じた。システムテストで使う Capybara は RSpec ともまた違う記法を使ったりもするので、RSpec をマスターするのは予想以上にコストが高そうに感じた。
一方で、マスターすれば効果的かつ自在なテストを書くことができる印象を受けたので、Rails を軸とする開発に携わった際には是非マスターしたいと感じた。

期待する結果は能動形で明示的に記述すること。example の結果がどうなるかを動詞を使って説明するようにする。チェックする結果は example 一つに付き一個だけにする。
起きてほしいことと、起きてほしくない両方をテストすること。example を書くときは両方のパスを考えてテストを書く。
境界値テストをすること。もしパスワードのバリデーションが 4 文字以上 10 文字以下なら、4 文字と 10 文字、3 文字と 11 文字もテストするのが良いテストケース。
テストを書くことは、アプリケーションの要件について見返すのに良い機会でもある。
可読性を上げるためにスペックを整理する。
- describe と context によりよく似た example を分類してアウトライン化する。
- before ブロックと after ブロックにより重複を除去する。
テストの場合は DRY であることよりも読みやすいことの方が重要。
- スペックファイルのあちこちを参照しなければならない場合、ちょっとぐらいリピートしても問題ない。

コントローラのテストは Rails や RSpec から完全にはなくなっていないものの、最近では時代遅れのテストになっている。コントローラのテストに限界があるためである。
そのため、筆者が開発しているアプリケーションでは、コントローラのテストはアクセス制御が正しく機能しているか確認するテストに限定している。
コントローラのテストは対象となる機能の単体テストとして最低限活用できるときだけ使うのがよい。使いすぎないように注意。

テスト内や複数のテストファイルにまたがるコードの重複を減らし、テストコードを DRY にすることも重要。長い目で見たときに保守しやすいテストコードを作ることができる。