hacomonoのRailsプロダクトにおけるテストの実状とこれから

【カミナシ x hacomono】成長過程のスタートアップに必要な開発者体験について考える

セッション②
hacomonoのRailsプロダクトにおけるテストの実状とこれから

株式会社hacomono
エンタープライズ部 エンジニアリングマネージャー

ソフトバンク、セールスフォース、freee、スタートアップCTO、メルカリ、カンカクを経て、2023年6月にhacomonoへ入社。バックエンドを中心にモバイル、インフラ、フロントエンド開発に従事。 仕事で大切にしていることは「論よりコード」。実装の相談を受けた際にあれこれ理論や想像を押し付けるのではなく、コード (PR) で示す。

Transcript

1. Last Update 2022.03.16 hacomono の Rails プロダクトにおける テストの実状とこれから @h2z
2. 2 自己紹介 @h2z / htz (西脇 正志) • 株式会社 hacomono プロダクト開発本部 • Softbank → Salesforce → freee → メルカリ (ソウゾウ, メルペイ) → カンカク → 今ここ • 趣味: 卓球, 子育て, プログラミング
3. section 0 hacomonoについて 3
8. section htz が考える hacomono の開発者体験 1
9. 9 • 伝統的な経緯を含む複雑な仕様や実装が無く、新しいメンバーも すぐに開発に入れる • テストが羅的に記述されており、大きめのアップデートやリリースの 際にも安心感が高い • CI の待ち時間が少なく、素早く開発やリリースを回すことが出来る • 負債を回収する文化と時間を開発の中で割り当てることが、個人 の裁量内で出来る アプリ開発者としての良い開発体験とは？
10. 10 〝テストが網羅的に記述されており、 新しいメンバーも安心してストレスの無い開発が行える環境が 組織的に提供されていること〟 アプリ開発者としての良い開発体験とは？
11. section hacomono における Rails テストの実状 2
12. 12 • 通常の Rails アプリケーションではなく、Rails にクリーンアーキテクチャが適用され た構成になっている • コントローラー (Rails) • ドメイン層 • データ層 (ActiveRecord) 前提知識: hacomono でのアーキテクチャ 詳しくは 「Ruby/Rails + Clean Architecture で API サーバーを実装してみる - Qiita」
13. 13 • 一部アプリケーションをモジュラーモノリスとして切り出して開発している 前提知識: hacomono でのアーキテクチャ 詳しくは 「モノリスなRailsにモジュラーモノリスを導入した話 - hacomono TECH BLOG」
14. 14 • Rails のテストは全て RSpec により記述されている • テスト構成 ◦ コントローラー => リクエストテスト ◦ ドメイン層 => 単体テスト ◦ データ層 => 単体テスト ※ Rails 側は全て API で画面は持っていないため、 フロントを絡めた E2E テスト (システムテスト) は存在しない Rails アプリのテスト構成
15. 15 • Example 数: かなりの数 • カバレッジ: 94.18% • リクエストテストの割合: 82.4% • CI が 40 分近くかかる (matrix で 6 分割済み) ◦ GitHub Actions の時間としては 1 CI に 5 時間 テスト (RSpec) を数字で見てみる
16. 16 • Example 数: かなりの数 • カバレッジ: 94.18% • リクエストテストの割合: 82.4% • CI が 40 分近くかかる (matrix で 6 分割済み) ◦ GitHub Actions の時間としては 1 CI に 5 時間 テスト (RSpec) を数字で見てみる
17. 17 リクエストテストの割合が 82.4%
18. 18 リクエストテストって？ • RSpec で Controller 層のテストを書く時に RSpec として推奨されているテスト手法 • クラス単体のテストを行う単体テストとは違い、routes.rb に定義されたエンドポイントに 対して実際に HTTP リクエストを行いテストを行う • テストの際は極力スタブ (モック) は利用せず、内部結合テスト的な意味合いで書かれる
19. 19 メリット・デメリット • メリット ◦ API 単位での IN と OUT で RSpec を記述できるため、フロントエンド側から見た仕 様と対になり把握し易い ◦ 内部の細かな実装や動作条件を一箇所に集めてテストする事が出来る • デメリット ◦ 実際のデータを用意する必要があるため、テスト数が多いとパフォーマンスに影 響する ◦ 細かな内部実装も全てリクエストテストの条件 (context) として詰め込まれるた め、テストの実装とメンテナンスの難易度が高い
20. 20 現状の課題 • CI に40 分近くの時間がかかる ◦ RSpec の CI 自体は 6 分割で動いているため、 GitHub Actions 時間としては 5 時間超え • リクエストテストの割合が多く、単体テストが書かれていないクラスが多数存在する ◦ 単体テストでのカバレッジが少なく不安がある • RSpec の書き方が人によりまちまちで、テストデータの作成方法自体も統一感がない ◦ FactoryBot の利用、Entity を直接作成、Usecsse 層を呼び出して作成、etc. • shared_context を利用したテストデータ作成 (内部に大量の let が存在) があり、各箇所で伝統的 に利用されている ◦ 物によっては 100 個近くの let! が詰め込まれている物も、、、 • 不安定なテスト (Flaky test) が頻繁に発生 (潜在) しており、PR でのテストが通らない事が多い ◦ 現在時刻の違いによって落ちる (日替わり、月末、月初) ◦ リスト取得のテストをインデックスを利用して確認
21. section 今やっていること 3
22. 22 • やったこと ◦ GitHub Actions での matrix によるテスト分割に加えて parallel_tests での並列テストを追加 ← 最近導入 ◦ リクエストテストを少なくし、単体テストを増やす ◦ テストデータ作成を必要最低限にする • 結果 ◦ 30 分を切るくらいまでは短縮している 🎉 ◦ が、10分は切っていきたい CI 時間の短縮
23. 23 リクエストテストを少なくし、単体テストを増やす • やったこと ◦ 単体テストを書く習慣と文化を定着化させるための啓蒙活動 ◦ RSpec でのテストの書き方やスタイルガイド等の社内ドキュメント を整備 • 結果 ◦ htz が入社時に 82.4% あったリクエストテストが 75.3% まで減っ てきている ◦ が、本当は数字としては真逆、単体テストを 80% くらいまで上げ ていきたい
24. 24 改善傾向あり
25. 25 テストデータの作成方法の統一感がない • やったこと ◦ FactoryBot が効率よく利用できるように、全 Factory の見直しとリ ファクタリング ◦ FactoryBot を使える箇所は積極的に書き換え ◦ FactoryBot の作成・利用方法に関する社内ドキュメントの記述 ◦ 間違った Factory が作成されている箇所を発見する RSpec の記 述 • 結果 ◦ 全ての Factory が正しく使えるところまでの準備は整った ◦ shared_context によるデータ作成を含め気合を入れて見直し
26. 26 テストを安定して動かす • やったこと ◦ ボーイスカウトルールで自身の PR で落ちたテストは出来るだけ修 正 ◦ 修正した PR を出来るだけエンジニアチャンネルへ共有し新たな不 安定なテストが生まれないようにする • 結果 ◦ まだまだ全然減っていない ◦ リクエストテストだとあらゆる条件下で不安定になっているテストも あるため、単体テスト化も含め進めていく
27. section これから 4
28. 28 • 今やっている施策をより推進してく ◦ ボランティアベースではなく業務内で数字 (KPI) を持って進めてい ける体制づくり • 既存機能も積極的にモジュラーモノリス化を進める過程で単体テスト の割合を増やしていく ◦ 既存に対してテストを書くモチベーションはなかなか上がらないけ ど、リファクタリングのタイミングならワンチャン！ • マイナスをゼロにする施策だけでなく、メンバー発信でプラスにしていく 施策が出来る組織づくりを行っていく これからの構想
29. https://www.hacomono.jp/