monorepo の Go テストをはやくした〜い！~最小の依存解決への道のり~ / faster-testing-of-monorepos

Go Bash #2 で喋った内容です
https://layerx.connpass.com/event/367057/

Transcript

1. monorepo のテストを早くしたい！ ~最小の依存解決への道のり~ 2025/10/06 Go Bash vol.2 @convto
2. 自己紹介 © LayerX Inc. convto (よみは「こんぶと」です) LayerX (2023-03 -) バクラク事業部アカウント基盤開発部 ID チーム 2023-03 ~ 2023-09 まで申請/経費精算などのプロダクト担当 2023-09 くらいからID基盤の開発に関わっています 2
3. テストやってますか
4. テスト、早くしたいですよね © LayerX Inc. 早ければ早いほどいい なぜかどんどん遅くなる 困る 4
5. テストはなぜ遅くなる？ © LayerX Inc. コード行数が増える 実行するテストケースが増える 5
6. テストはなぜ遅くなる？ これ自体は悪いことではない 健全に事業成長している証拠 でもある どんな管理をしていても、ソフトウェア規模が大きくなるとぶつかる問題 © LayerX Inc. コード行数が増える 実行するテストケースが増える 6
7. LayerX では monorepo でバックエンド開発をしています © LayerX Inc. 単一のリポジトリに複数のアプリケーション、ライブラリ、スキーマ定義など monorepo でも問題の構造は変わらない 一方レポジトリの膨張速度は速い その結果 諸問題が早期に顕在化しやすい 7
8. 大きいコードベースでも テストを早くしたい
9. 早くするための手法 © LayerX Inc. コードを小さくする 不要なテストケースを減らす キャッシュする 実行箇所を限定する etc… 9
10. 早くするための手法 © LayerX Inc. コードを小さくする 不要なテストケースを減らす キャッシュする 実行箇所を限定する etc… 10
11. 実行箇所を限定した差分テスト
12. どうやって差分テストをやるか © LayerX Inc. ソースコードにはそれぞれ依存関係がある 変更した差分を起点に依存を解決させていけば 最小の影響範囲 がわかる いうは易しやるのは超大変だし〜 12
13. どうやって差分テストをやるか こういうグラフがあったとして © LayerX Inc. 13
14. どうやって差分テストをやるか B'' を変更したら A / B / A' / D' / B'' だけテスト実行されたい © LayerX Inc. 14
15. 差分テスト実行の現在地
16. パッケージ単位の差分解決ができている https://pkg.go.dev/golang.org/x/tools/go/packages にドキュメントあるので気になる方はぜひ！ © LayerX Inc. パッケージ単位の import graph を構築 x/tools/go/packages を利用して import 関係を読み込み、木に整形 変更パッケージからから到達可能なパッケージをリスト テスト実行 16
17. パッケージ単位の差分解決ができている このあたりは @ktr さんが過去発表しているので、詳細はそちらをどうぞ © LayerX Inc. 17
18. 処理の流れざっくり © LayerX Inc. 変更の特定 GitHub CLI を使って PR で変更されたファイルを取得 影響分析 静的解析を使ってパッケージ単位の依存グラフを作成 影響を受けるパッケージを特定 選択的テスト実行 変更によって影響を受けるパッケージのテストのみを実行 18
19. 成果 この試みは一定の成果を出していて当時 1~2min のテスト高速化ができました © LayerX Inc. 19
20. いまの困りごと
21. 困り1: めちゃでかパッケージくん [service pkg] < 私のコード行数は53万です、ですがもちろんフルパワーであなたとテストする気はありませ んからご心配なく… [convto] < きみのpkgのテスト実行するだけで4分かかるんだけど © LayerX Inc. 21
22. 困り1: めちゃでかパッケージくん © LayerX Inc. かわいそうですね 1パッケージが大きいケースでは起きうる レイヤ分け系のアーキテクチャだとよくありそう 22
23. 困り2: 根っこのpkgが引っかかると結局全部連れてくる [domain] < あちゃーおれも依存に含まれちゃったか [service / repository] < マブなんで俺らも出ますよ [handler] < service さんが行くなら僕も… [convto] < 結局全員相手せなあかんやないかい © LayerX Inc. 23
24. 困り2: 根っこのpkgが引っかかると結局全部連れてくる © LayerX Inc. かわいそうですね 依存の根っこの方のパッケージが含まれると起きがち 24
25. もっと最小の依存にしたい
26. さらに実行対象を絞りたい © LayerX Inc. さっきはパッケージ単位だった 関数呼び出しなど、もっと絞ればもっと早くなるのでは！ 26
27. さらに実行対象を絞りたい さっきの依存の図 © LayerX Inc. 27
28. さらに実行対象を絞りたい 関数レベルまでみると実は依存を絞れる！ © LayerX Inc. 28
29. 関数単位の依存解決 © LayerX Inc. パッケージとしては依存してても、実際の変更箇所の処理には依存していないケースは 多々ある 関数呼び出しの call graph みたいなのを作って依存解決すれば優勝できそう テストも実際の関数呼び出しをしてるので、テスト関数自体もそのグラフに繋がってる かを見れば テスト実行の必要性がマークできる 29
30. 関数単位の依存解決 今の状態 © LayerX Inc. PoC はできて、動くものが作れることはわかった x/tools/x/packages は AST も要求できるので、それを受け取る ガバっと見て関数呼び出しの依存解決する が、課題も見えてきている 素朴な解析、探索だとパフォーマンスの問題がありそう Go 本体がどうやって依存解決してるかなど参考にしたい PoC は関数だけだったが type / interface / const / var など公開されてる識別子も検証必要 30
31. まとめ © LayerX Inc. モノレポのテストは成長とともに遅くなる パッケージベースの差分テストでもまだ改善の余地がある コールグラフベースのアプローチでより精密な影響範囲特定を目指す 課題があるがいい感じの解決ができると嬉しい 31
32. ご清聴ありがとうございました！