Rails更新は最低限Controllerのテストが欲しいというお話

じゅんてつです。

2019年はRails4.2のサポートが切れましたが、みなさんのプロダクトは更新されましたか？Rails更新の際に「Rails アップグレードガイド - Rails ガイド」を参照しているひとが多いと思いますが、まず一番最初に「テスティングのカバレッジ」の話が出てきますよね。

「テスティングのカバレッジってどこまでやればいいの？」

って思ったことありませんか？私はあります。

クラウドワークスのプロダクトのRails5.2に更新した経験から「Controllerのテスト、特に正常系が1パターンあれば最低限どうにかなった」という体感値を得ましたので、簡単に紹介したいと思います。

クラウドワークスのRails更新で難しかったこと（課題）

• Rubyだけで30万行超の規模で、全体を把握している人間がいなかった
• モノリシックな作りでRailsの変更がどこに影響がでるか把握できなかった
  • 削除または動作が変わったメソッドが与える影響など
• テストが存在しない機能が多々あった

最低限の検知する方法として、自動テストがないと安全には進めないプロダクトだと感じました。逆に、ある程度は安心できるような仕組みもありました。

• Fat Modelに関するSpecが充実していたので安心
• 継続的インテグレーション(CI)の環境が整っていたので安心

先人の汗と涙の上にできあがっている仕組みだと思うと涙が・・・。

何をしたか？

Rails5で動かした際、変更点が起因してModelが壊れたら呼び出してるControllerのテストも落ちるよね？という発想で、Controllerのテストを充実させようしました。内容はRails4の状態でController Spec と Request Specを実装していくというもの。レスポンス 200 やリダイレクトを確認するブラックボックステストしか用意できないものもありましたが、コスト以上の恩恵¹を得られました。

どういう恩恵を得たのか？

結果として、機能の死活監視ができるようになり変更が影響する機能がわかるようになりました。もちろん組み合わせをカバーできたわけではないので動作確認を挟む必要はありましたが、アクセスしただけで落ちるようなエラーは事前に検知できて潰し込めるようになりました。

クラウドワークスはおよそ2000のURLが定義されているため、とりあえず生きてるのか死んでるのかが知れるだけでも非常に助かりました。

検知できない影響は？

動作は変わったけど正常にレスポンス返しちゃうような変更を検知できません。例えば、ActiveRecord が発行するクエリが変わる変更があったら検知できません。今回はそういった類はなさそうだったのでセーフ。

実際のところ気づいていないだけかもしれないけど、それ検知できるようなら何も心配ないレベルまでテストそろった状態だよね。

Feature Specじゃダメだったの？

多くは語りませんが、Feature Specは採用されませんでした。

• 網羅的に実装するにはパターンが多い(プロダクト規模に起因)
  • クリティカルな機能に絞って実装しようとしても同様であった
  • どこまで実装すれば安心できるのか、誰も言語化できなかった
  • Rails更新以外の変更に敏感で、運用コストが・・・

まとめ

• 最低限Controllerのテストがほしい
  • テストは無いよりあったほうが良い、あればあっただけ死活監視ができて安心できる
  • Request Specなどのブラックボックステストは最低限欲しい
  • Controller Specがあればなお良い

あくまで「どうにかなった最低限」なので安心安全を保証するものではありませんが、Rails更新の一つの基準になればと思います。

あわせて読みたい記事

Rails4へ移行しましたのご報告とブログ連載のお知らせ - クラウドワークス エンジニアブログ

注釈

1. 時間(金銭)的なコストを掛けて、リスク、確認の実工数、精神的コストの低減のリターン ↩