少し前にRuby on Railsのテストカバレッジが60%程度でそこから75%を目指して、
3か月取り組んでいくという記事を書きましたが、今回はその振り返りになる記事です。
具体的にやったことや結果について共有できればと思っています。
やったこと
カバレッジ計測対象の見直し
開発環境やStaging環境でのテストを簡単にするために定義したControllerや、
初期データ投入用のRakeタスクも当然計測対象に入っているのですが、これらは計測してもあまり意味がないので .simpleconv でいくつかのControllerやRakeタスクは計測しないようにしました。
Coverband導入してコードの削除を進めていく
Coverbandは実際のProduction環境でコードの実行状況を可視化するツールです。
下記のようにテストカバレッジのように可視化されます。
Webでのリクエストはあったかなどは、弊社の分析基盤であるGoogle BigQueryであったりで、リクエストがあったかをログでチェックしたりするのですが、まず消せそうか？使われていなさそうか？の一次調査のためにCoverbandの導入はかなり役立ちました。
これらのツールを活用して未利用コードの削除を進めていきました。
あとはとにかくテストを追加していく
テストカバレッジ計測対象を絞り込んだり、実行されていないコードを削除しつつも、
実際にはとにかくテストの追加を行っていくことが作業のほとんどでした。
毎日simplecovでのカバレッジレポートをざっくり眺めながら、効果の大きいものからテストの追加を行ってきました。
先述の記事にもあるように日々の開発に加えてテストカバレッジ向上のためのタスクを起票して、
日々の機能改善と並行しながら進めていきました。
Controller Spec
弊プロダクトは機能数も多く、Controllerの数も行数も多い傾向にあったので、
重要な画面のControllerからテストをひたすら追加していきました。
機能の重要度にもよりますが、細かくSpecを網羅的に書くというよりは簡単なSpecでよいので、
テストが行われているControllerを増やすことを意識してSpecを追加していきました。
結果
計測を開始した4月初めと最終的な6月末時点の結果です。
| All | Controller | Model | Mailers | Helpers | Jobs | Lib | Ungrouped | |
| 2024/04/04 | 64.66% | 46.16% | 78.20% | 96.62% | 53.70% | 53.91% | 40.92% | 55.09% |
| 2024/06/27 | 75.19% | 64.74% | 83.76% | 96.83% | 62.94% | 62.43% | 49.67% | 64.67% |
見事に75%に入れることができて目標達成となりました🎉🎉
特にControllerSpecの単体で見た時にカバレッジは46%から64.7%まで向上しました。
まだ改善の余地はありますが、重要なControllerに対してのSpecはある程度網羅されているような状況まで持っていくことができました。
やってよかったか？
品質における目標として、テストカバレッジを設定したのは良かったと思いましたし、
60% -> 75%という目標設定はちょうどよい設定かなと思っています。
Spec追加は不具合修正や機能改善は行っているはずで、その際に「おっ、テスト書かないと」だったり、コードレビューだったりで、テストカバレッジを目標においているからこそ、こういう観点のテストがあるとよいみたいな話がちらほらあったりで意識するきっかけになったのは大きかったです。
数値やチーム内以外の効果としては、プロダクトがリリースされてから9年目ということもあり、
それなりに機能として重要な責務を担うControllerだったりにSpecがない状態だったりであるということも対応過程でわかり、その状況が打破できたのは今後の機能改善のことを考えると本当によかったなという次第です。
反省点としては最後の方は他のメンバーも少し余裕がない状態だったので、
目標達成のためにテストコードを追加するために結構数日間で私個人がパワープレイをしてしまったというところでしょうか。
今後取り組むこと
元々バックエンドのテストカバレッジは60%超えていたので、その程度にはテストされていて全くテストがないということではありませんでしたし、カバレッジを伸ばしていく過程で少しずつですが、安心感をもって機能開発を進めるようになってきている感覚はありました。
しかし、フロントエンドはほぼユニットテストを書いておらず、代わりにフロントエンド側の問題が目立つようになりました。
フロントエンドは動作チェックなど正常系のみをリグレッションテストとして行い動作を担保している状態で、細かい失敗パターンなどのケースが網羅できているわけではないためです。
フロントエンドアーキテクチャの一部見直し
そこで、私たちはバックエンドにビジネスロジックを寄せていったり、RailsでHTMLやViewを組み立てることができればおのずと品質は上がるのではないか？という仮説もあり、先日投稿したフロントエンドアーキテクチャの見直しを行うことになりました。
これは弊社の在籍メンバーがバックエンドエンジニアが中心なので、品質担保においては慣れていて都合が良いという判断もあって対応を決断しました。
他の選定理由などについては下記記事にもまとめているので、よろしければこちらもご覧ください。
テスト範囲が広がればカバレッジは下がる
これまでJSONを返すだけだったControllerはHTMLを返すようになり、
サーバーサイドのロジックが増え、ViewだけでなくHelperなど色々増えることが想定されるため、当然テストが追加されなければカバレッジは下がってしまいます。
カバレッジの数値向上を優先するではなく、
Railsのテストで品質保証できる幅を広げることを次の3か月は優先して、カバレッジは維持できればいったんOKということで、カバレッジの向上を目標に入れるのはやめています。
そのうえで、2024年中にカバレッジが80%にすればよいというゴールの達成が事業貢献しながら品質保証をしていくというのがバランスが取れていて良いのかなと考えています。
合わせてJestでJSのユニットテストを書く
すでに、フロントエンドにいくつか存在していた、重要なビジネスロジックをバックエンドに寄せていますが、それでもフロントエンドにあるビジネスロジックをゼロにするのは難しいですし、かえって開発しづらい部分もあると思います。そのため、フロントエンドにあるビジネスロジック部分を単純な関数であったりに切り出し、ユニットテストをしやすいようにし、フロントエンドでもユニットテストを書いて品質担保や開発効率を向上できればと思っています。
おわりに
ひとまず目標達成したので、3か月の継続的なプロジェクトとしてのカバレッジ向上は終了しますが、
次にRailsでのSpecで品質保証できる幅を広げる対応を行って、プロダクトの品質向上にチームとして務めていければと思っています。
Discussion