Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
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/