Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

2 自己紹介 @h2z / htz (西脇 正志) ● 株式会社 hacomono プロダクト開発本部 ● Softbank → Salesforce → freee → メルカリ (ソウゾウ, メルペイ) → カンカク → 今ここ ● 趣味: 卓球, 子育て, プログラミング

Slide 3

Slide 3 text

section 0 hacomonoについて 3

Slide 4

Slide 4 text

4


Slide 5

Slide 5 text

5


Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

section htz が考える hacomono の開発者体験 1

Slide 9

Slide 9 text

9 ● 伝統的な経緯を含む複雑な仕様や実装が無く、新しいメンバーも すぐに開発に入れる ● テストが羅的に記述されており、大きめのアップデートやリリースの 際にも安心感が高い ● CI の待ち時間が少なく、素早く開発やリリースを回すことが出来る ● 負債を回収する文化と時間を開発の中で割り当てることが、個人 の裁量内で出来る アプリ開発者としての良い開発体験とは?

Slide 10

Slide 10 text

10 〝テストが網羅的に記述されており、 新しいメンバーも安心してストレスの無い開発が行える環境が 組織的に提供されていること〟 アプリ開発者としての良い開発体験とは?

Slide 11

Slide 11 text

section hacomono における Rails テストの実状 2

Slide 12

Slide 12 text

12 ● 通常の Rails アプリケーションではなく、Rails にクリーンアーキテクチャが適用され た構成になっている ● コントローラー (Rails) ● ドメイン層 ● データ層 (ActiveRecord) 前提知識: hacomono でのアーキテクチャ 詳しくは 「Ruby/Rails + Clean Architecture で API サーバーを実装してみる - Qiita」

Slide 13

Slide 13 text

13 ● 一部アプリケーションをモジュラーモノリスとして切り出して開発している 前提知識: hacomono でのアーキテクチャ 詳しくは 「モノリスなRailsにモジュラーモノリスを導入した話 - hacomono TECH BLOG」

Slide 14

Slide 14 text

14 ● Rails のテストは全て RSpec により記述されている ● テスト構成 ○ コントローラー => リクエストテスト ○ ドメイン層 => 単体テスト ○ データ層 => 単体テスト ※ Rails 側は全て API で画面は持っていないため、 フロントを絡めた E2E テスト (システムテスト) は存在しない Rails アプリのテスト構成

Slide 15

Slide 15 text

15 ● Example 数: かなりの数 ● カバレッジ: 94.18% ● リクエストテストの割合: 82.4% ● CI が 40 分近くかかる (matrix で 6 分割済み) ○ GitHub Actions の時間としては 1 CI に 5 時間 テスト (RSpec) を数字で見てみる

Slide 16

Slide 16 text

16 ● Example 数: かなりの数 ● カバレッジ: 94.18% ● リクエストテストの割合: 82.4% ● CI が 40 分近くかかる (matrix で 6 分割済み) ○ GitHub Actions の時間としては 1 CI に 5 時間 テスト (RSpec) を数字で見てみる

Slide 17

Slide 17 text

17 リクエストテストの割合が 82.4%

Slide 18

Slide 18 text

18 リクエストテストって? ● RSpec で Controller 層のテストを書く時に RSpec として推奨されているテスト手法 ● クラス単体のテストを行う単体テストとは違い、routes.rb に定義されたエンドポイントに 対して実際に HTTP リクエストを行いテストを行う ● テストの際は極力スタブ (モック) は利用せず、内部結合テスト的な意味合いで書かれる

Slide 19

Slide 19 text

19 メリット・デメリット ● メリット ○ API 単位での IN と OUT で RSpec を記述できるため、フロントエンド側から見た仕 様と対になり把握し易い ○ 内部の細かな実装や動作条件を一箇所に集めてテストする事が出来る ● デメリット ○ 実際のデータを用意する必要があるため、テスト数が多いとパフォーマンスに影 響する ○ 細かな内部実装も全てリクエストテストの条件 (context) として詰め込まれるた め、テストの実装とメンテナンスの難易度が高い

Slide 20

Slide 20 text

20 現状の課題 ● CI に40 分近くの時間がかかる ○ RSpec の CI 自体は 6 分割で動いているため、 GitHub Actions 時間としては 5 時間超え ● リクエストテストの割合が多く、単体テストが書かれていないクラスが多数存在する ○ 単体テストでのカバレッジが少なく不安がある ● RSpec の書き方が人によりまちまちで、テストデータの作成方法自体も統一感がない ○ FactoryBot の利用、Entity を直接作成、Usecsse 層を呼び出して作成、etc. ● shared_context を利用したテストデータ作成 (内部に大量の let が存在) があり、各箇所で伝統的 に利用されている ○ 物によっては 100 個近くの let! が詰め込まれている物も、、、 ● 不安定なテスト (Flaky test) が頻繁に発生 (潜在) しており、PR でのテストが通らない事が多い ○ 現在時刻の違いによって落ちる (日替わり、月末、月初) ○ リスト取得のテストをインデックスを利用して確認

Slide 21

Slide 21 text

section 今やっていること 3

Slide 22

Slide 22 text

22 ● やったこと ○ GitHub Actions での matrix によるテスト分割に加えて parallel_tests での並列テストを追加 ← 最近導入 ○ リクエストテストを少なくし、単体テストを増やす ○ テストデータ作成を必要最低限にする ● 結果 ○ 30 分を切るくらいまでは短縮している 🎉 ○ が、10分は切っていきたい CI 時間の短縮

Slide 23

Slide 23 text

23 リクエストテストを少なくし、単体テストを増やす ● やったこと ○ 単体テストを書く習慣と文化を定着化させるための啓蒙活動 ○ RSpec でのテストの書き方やスタイルガイド等の社内ドキュメント を整備 ● 結果 ○ htz が入社時に 82.4% あったリクエストテストが 75.3% まで減っ てきている ○ が、本当は数字としては真逆、単体テストを 80% くらいまで上げ ていきたい

Slide 24

Slide 24 text

24 改善傾向あり

Slide 25

Slide 25 text

25 テストデータの作成方法の統一感がない ● やったこと ○ FactoryBot が効率よく利用できるように、全 Factory の見直しとリ ファクタリング ○ FactoryBot を使える箇所は積極的に書き換え ○ FactoryBot の作成・利用方法に関する社内ドキュメントの記述 ○ 間違った Factory が作成されている箇所を発見する RSpec の記 述 ● 結果 ○ 全ての Factory が正しく使えるところまでの準備は整った ○ shared_context によるデータ作成を含め気合を入れて見直し

Slide 26

Slide 26 text

26 テストを安定して動かす ● やったこと ○ ボーイスカウトルールで自身の PR で落ちたテストは出来るだけ修 正 ○ 修正した PR を出来るだけエンジニアチャンネルへ共有し新たな不 安定なテストが生まれないようにする ● 結果 ○ まだまだ全然減っていない ○ リクエストテストだとあらゆる条件下で不安定になっているテストも あるため、単体テスト化も含め進めていく

Slide 27

Slide 27 text

section これから 4

Slide 28

Slide 28 text

28 ● 今やっている施策をより推進してく ○ ボランティアベースではなく業務内で数字 (KPI) を持って進めてい ける体制づくり ● 既存機能も積極的にモジュラーモノリス化を進める過程で単体テスト の割合を増やしていく ○ 既存に対してテストを書くモチベーションはなかなか上がらないけ ど、リファクタリングのタイミングならワンチャン! ● マイナスをゼロにする施策だけでなく、メンバー発信でプラスにしていく 施策が出来る組織づくりを行っていく これからの構想

Slide 29

Slide 29 text

https://www.hacomono.jp/