Railsでエンドポイントごとのテストカバレッジを測定する / Measuring Test Coverage per Endpoint in Rails

Railsでエンドポイントごとのテストカバレッジを測定する話です。

以下リンク

Railsアップグレードを楽にする取り組み 〜社内向け管理画面編〜
https://tech.timee.co.jp/entry/2023/12/05/000000

Timee Advent Calendar 2023
https://qiita.com/advent-calendar/2023/timee

今回作ったスクリプト
https://gist.github.com/euglena1215/61f8e400b98e8a37d50232d007663a18

ChatGPT 先生の履歴
https://chat.openai.com/share/0cb3ce7d-36f8-4b71-af04-b01b177a22c2

Transcript

1. 2023/12/07　【オフライン開催】Omotesando.rb #92 株式会社タイミー　新谷哲平 Railsでエンドポイントごとの テストカバレッジを測定する @euglena1215
2. 自己紹介 新谷 哲平（@euglena1215） • 株式会社タイミー • バックエンドエンジニア • omotesando.rb 参加5回目 • マリオRPGの連続ジャンプ30回超えないので 誰かコツを教えてください
3. 2023/12/07　【オフライン開催】Omotesando.rb #92 株式会社タイミー　新谷哲平 Railsでエンドポイントごとの テストカバレッジを測定する @euglena1215
4. 目次 • なぜやろうと思ったのか • 実現方法 • 結果
5. 【宣伝】アドベントカレンダーの記事の抜粋です 今回の発表はTimee Advent Calendar 2023 シリーズ1 5日目 記事の抜粋です。 https://tech.timee.co.jp/entry/2023/12/05/000000 Timee Advent Calendar 2023 はこちら： https://qiita.com/advent-calendar/2023/timee
6. 1 なぜやろうと思ったのか
7. なぜやろうと思ったのか タイミーでは Rails アップグレードでの動作確認は 基本的には手動でポチポチしなくてOK。 理由： テストカバレッジが91%と比較的高く、 十分に動作が担保できている前提があるため。
8. なぜやろうと思ったのか 例外として... 社内向け管理画面は手動での動作確認が必要。
9. なぜやろうと思ったのか 例外として... 社内向け管理画面は手動での動作確認が必要。 理由： 社内向け管理画面のテストカバレッジが低く、自動テストが信用できない 😢
10. なぜやろうと思ったのか 例外として... 社内向け管理画面は手動での動作確認が必要。 理由： 社内向け管理画面のテストカバレッジが低く、自動テストが信用できない 😢 もっと楽して Rails アップグレードしたい！！
11. そのためにはテストを増やす必要あり。テストを増やす前に目標を決めたい。 なぜやろうと思ったのか まずは指標を定義することに
12. まずは simplecov gem で計測していた Code Line Coverage を指標として考え ることに。 指標その１：Code Line Coverage
13. まずは元々 simplecov gem で計測していた Code Line Coverage を指標として 考えることに。 指標その１：Code Line Coverage Code Line Coverage はこういったやつ。 テスト中に実行されたコードと実行されていない コードを区別し、実行された割合を算出する。
14. まずは simplecov gem で計測していた Code Line Coverage を指標として考え ることに。 しかし、ActiveAdmin においては問題があることがわかった。 指標その１：Code Line Coverage
15. Code Line Coverage の問題点 ActiveAdmin における最小構成の実装をすると
16. Code Line Coverage の問題点 9つものエンドポイント（≒機能）が定義される
17. Code Line Coverage の問題点 このファイルが読み込まれただけで全ての行が実行されたことになるので、 テスト書いてなくても Code Line Coverage は 100% になる。
18. ActiveAdmin は高機能な DSL によって数行でいくつもの画面を生成できるた め、機能数とコードの行数が比例しない。 そのため、ActiveAdmin を使った管理画面の実装において Code Line Coverage は指標として不適切だろうと判断。 指標その１：Code Line Coverage 別の指標を検討することに
19. ActiveAdmin において機能数と比例するものはエンドポイント数。 エンドポイントに対して1つ以上対応したテストがあれば一定動作は保証されて るだろうと考えた。 そこで、/admin/* のエンドポイントに対して request spec が何割カバーできて いるかを指標とすることに。 これを Endpoint Coverage と呼んでみる。 指標その２：Endpoint Coverage
20. 指標その２：Endpoint Coverage
21. 2 実現方法
22. なるべくシンプルな方法で Endpoint Coverage を集計してみる。 実現方法
23. なるべくシンプルな方法で Endpoint Coverage を集計してみる。 実行ステップ 1. rails routes 相当の情報を取得 2. spec/requests/* ファイルを読み込みルーティングに対応する describe 句 を抜き出す 3. 1.と2.で得られたデータを組み合わせて、テストされているエンドポイント ・テストされていないエンドポイントを分類する 4. 割合を算出する 実現方法
24. 1. rails routes 相当の情報を取得
25. 1. rails routes 相当の情報を取得
26. 2. spec/requests/* ファイルを読み込み ルーティングに対応する describe 句を抜き出す
27. 2. spec/requests/* ファイルを読み込み ルーティングに対応する describe 句を抜き出す
28. 3. 1.と2.で得られたデータを組み合わせて、 テストされているエンドポイント・テストされていない エンドポイントを分類する
29. 3. 1.と2.で得られたデータを組み合わせて、 テストされているエンドポイント・テストされていない エンドポイントを分類する path と verb を比較して テストされていないものを集めているだけ
30. 3. 1.と2.で得られたデータを組み合わせて、 テストされているエンドポイント・テストされていない エンドポイントを分類する 4. 割合を算出する は割愛
31. 実現方法 コードはここに置いてます https://gist.github.com/euglena1215/61f8e400b98e8a37d50232d007663a18 今回のコードはほとんど ChatGPT に考えてもらいました https://chat.openai.com/share/0cb3ce7d-36f8-4b71-af04-b01b177a22c2
32. 3 結果
33. 結果
34. 結果 admin は 32.74%、全体は 55.26%。admin を抜いた全体は 78.91% admin とそれ以外とでは2倍以上の開きがあることが判明。やっていき💪
35. まとめ • Rails アップグレードを楽にするために社内向け管理画面のテストの信頼性 を上げたい • テストの信頼性の指標として、今回のケースでは Code Line Coverage より も Endpoint Coverage の方が良いと判断 • 実際に集計してみた結果、確かに社内向けとそれ以外では Endpoint Coverage に2倍以上の開きがあることがわかった
36. まとめ • Rails アップグレードを楽にするために社内向け管理画面のテストの信頼性 を上げたい • テストの信頼性の指標として、今回のケースでは Code Line Coverage より も Endpoint Coverage の方が良いと判断 • 実際に集計してみた結果、確かに社内向けとそれ以外では Endpoint Coverage に2倍以上の開きがあることがわかった 俺たちの戦いはこれからだ🔥 記事の方には少しだけ戦いの記録を書いてます