FactoryBotをやめればRSpecは速くなるのか？

Kaigi on Rails 2026 Day1
nissyiの登壇資料です。

https://kaigionrails.org/2026/talks/nissyi-gh/

Transcript

1.  FactoryBotをやめれば RSpecは速くなるのか？ 2026/10/16 Yuta Onishi 1
2. とうとう始まりましたね！ようこそ渋谷へ！
3. 自己紹介 Yuta Onishi (nissyi) SmartBank, Inc. Engineer @yuta̲onishi̲97 @nissyi-gh 3
4. 自己紹介 元 電車の運転士 Kaigi on Rails Organizer 4
5. X
6. テストにどれくらいの時間がかかっていますか？
7. テストにどれくらいの時間がかかっていますか？ ランチが終わったばかりだと思うので、体を動かしましょう🙋 7
8. テストにどれくらいの時間がかかっていますか？ テストの実行時間が… ・〜10分ぐらい 🙋 8
9. テストにどれくらいの時間がかかっていますか？ テストの実行時間が… ・〜10分ぐらい ・〜20分ちかく 🙋 9
10. テストにどれくらいの時間がかかっていますか？ テストの実行時間が… ・〜10分ぐらい ・〜20分ちかく ・20分〜！！！ 🙋 10
11. テストにどれくらいの時間がかかっていますか？ CIの実行時間が… ・〜10分ぐらい ・〜20分ちかく ・20分〜！！！ ・コードの規模やテスト方針などでさまざまだとは思いますが… 11
12. テストにどれくらいの時間がかかっていますか？ 速いに越したことはない 12
13. スマートバンクのテストは？
14. スマートバンクのテストは？ メインリポジトリでのテストを題材に話します ・RSpec ・FactoryBot ・system specなし ・並列実行 ・基本的にセルフホストランナー上で実行 14
15. スマートバンクのテストは？ ・以前は10分以上かかっていた ・メイン業務外の「委員会活動」により改善が進む ・2025年7月ごろには7分程度に👏 ・2026年3月ごろには5分程度にまで短縮 👏👏👏 15
16. 委員会活動により5分台へ短縮 https://speakerdeck.com/stefafafan/gha-ci-performance-tuning 16
17. 委員会活動により5分台へ短縮 https://speakerdeck.com/stefafafan/gha-ci-performance-tuning?slide=47 17
18. …そして時が経ち 日々開発が行われる 18
19. …そして時が経ち コードもテストも増えていく 19
20. …そして時が経ち …CI、遅くなってる気がする 20
21. …そして時が経ち CI、遅くなってる気がする 21
22. …そして時が経ち じわじわと上昇するトレンドライン 22
23. …そして時が経ち 遅くなってた 23
24. …そして時が経ち 高速にしたい 24
25. …そして時が経ち 高速にしたい けど、どうしたらいい？？ 25
26. 2025年に遭遇した、あのポスト DHHのとあるポストを思い出す 26
27. 2025年に遭遇した、あのポスト https://x.com/dhh/status/1919291397909233858 27
28. 2025年に遭遇した、あのポスト Railsのテストスイートを遅くしたければ、 FactoryBotを使うのが手っ取り早い。 私たちのHEYのテストスイートは、最新のLinuxマシンなら、 3万件を超えるアサーションが2分以内に終わる。 しかも、実際のデータベースを使って！ その秘密は？Rails Fixturesだ。 一度セットアップし、トランザクションで囲んで状態を リセットする。だから、ものすごく速い。 28
29. 2025年に遭遇した、あのポスト Rails Fixtures、そんなに速いのか！？ 29
30. 2025年に遭遇した、あのポスト Fixtures移行に挑戦してみたい！ 30
31. 今日話すこと
32. 今日話すこと ・Fixtures移行に挑戦した話 ・検証の結果、移行はしないという判断になった ・FactoryBotを使い続けながら、高速化に挑戦した話 ・スマートバンクのCIはどれくらい速くなったのか？ 32
33. 今日話すこと ・想定する聞き手 ・テスト高速化の手がかりを探している方 ・RSpecでFactoryBotを使っている方 ・テストの速度改善に興味がある方 33
34. 今日話すこと ・持ち帰ってもらえること ・テストのボトルネックを調べる方法 ・FactoryBot、Rails Fixtures、 let̲it̲be、FixtureKitの特徴と使い分け ・保守性や導入コストを含めて改善手段を選ぶための判断軸 34
35. Rails Fixturesとfactory̲botの比較
36. Rails Fixturesとfactory̲botの比較 Rails Fixtures ・テストの前提となる xtureをYAMLで定義 fi 36
37. Rails Fixturesとfactory̲botの比較 factory̲bot ・DSLで作り方を定義 ・必要なデータを柔軟に 作れる 37
38. Rails Fixturesとfactory̲botの比較 https://guides.rubyonrails.org/testing.html# xtures fi 38
39. Rails Fixturesとfactory̲botの比較 https://www.youtube.com/watch?v=jYsjAKDEuic 39
40. Rails Fixturesとfactory̲botの比較 https://www.youtube.com/watch?v=mHAx2onrIl4 40
41. Rails Fixturesとfactory̲botの比較 https://thoughtbot.github.io/factory̲bot/intro.html 41
42. なぜfactory̲botは遅くなりがちなのか?
43. なぜfactory̲botは遅くなりがちなのか? ・各exampleでcreateが 呼ばれ、レコードが INSERTされる ・関連レコードの生成でも、 追加のINSERTが発生する 43
44. なぜfactory̲botは遅くなりがちなのか? ・関連がさらに関連を 持つと、INSERTの数も 増える ・各exampleでこの処理を 繰り返すため、テスト 全体が遅くなりやすい 44
45. なぜFixturesは速くなりやすいのか？
46. なぜFixturesは速くなりやすいのか？ ・各exampleでデータを 作り直さず、投入済みの レコードを利用する ・̀books(:intro̲to…)̀ で、 対応するレコードを DBから取得する ※トランザクショナルテストを有効にした構成を前提とする 46
47. なぜFixturesは速くなりやすいのか？ ・FixtureデータをSQLで 直接DBに投入する ・投入時に、モデルの バリデーションや 保存時のコールバックを 実行しない ※トランザクショナルテストを有効にした構成を前提とする 47
48. Fixtures移行への挑戦
49. Fixtures移行への挑戦 「FactoryBotをやめてFixturesにしましょう」 49
50. Fixtures移行への挑戦 「FactoryBotをやめてFixturesにしましょう」 …なんて、いきなり言うわけにはいかない 50
51. Fixtures移行への挑戦 ・チームに導入するメリットデメリットとは？ 51
52. Fixtures移行への挑戦 チームに導入するメリットデメリットとは？ ・メリット ・DHHのポストのように高速なテストを実現できる（かも） ・デメリット ・FactoryBotと思想が大きく異なる ・今まで積み重ねたテストという資産を作り直すことになる ・移行コストが未知数 52
53. Fixtures移行への挑戦 移行コストについて検証が必要 ↓ いくつかのテストで移行してみることに 53
54. Fixtures移行への挑戦 ・チームに導入するメリットデメリットとは？ ・移行コストについて検証が必要 54
55. Fixtures移行への挑戦 ・チームに導入するメリットデメリットとは？ ・移行コストについて検証が必要 ・どう実現するか？ 55
56. Fixtures移行への挑戦 ・チームに導入するメリットデメリットとは？ ・移行コストについて検証が必要 ・どう実現するか？ ・静的解析にトライ 56
57. Fixtures移行への挑戦 静的解析にトライ ・RSpec・FactoryBotの定義を静的解析 ・ASTから何か情報を得られないか試行錯誤 ・自分のスキルでは、AI活用をしてもできなかった ・限られた時間の中では、現実味がない選択肢だった 57
58. Fixtures移行への挑戦 ・チームに導入するメリットデメリットとは？ ・移行コストについて検証が必要 ・どう実現するか？ ・静的解析にトライ ・AI(Opus 4.6)に作業させてみる 58
59. Fixtures移行への挑戦 AI(Opus 4.6)に作業させてみる ・それっぽい変換はできる ・既存のテストもPASSさせられる ・「Fixture定義が正しいかチェックするの大変！」 ・「しかも、めっちゃ時間かかる！！」 59
60. Fixtures移行への挑戦 ・チームに導入するメリットデメリットとは？ ・移行コストについて検証が必要 ・どう実現するか？ ・静的解析にトライ ・AI(Opus 4.6)に作業させてみる ・中間的な材料を生成して、変換の精度と確認のしやすさを上げる 60
61. Fixtures移行への挑戦 中間的な材料を生成して、変換の精度と確認のしやすさを上げる ・実装の確認→変換に時間がかかる ・FactoryBotの呼び出し履歴と、実行時のデータ生成を YAMLに記録する ・そのYAMLを元に変換作業させる ・「Fixture定義が正しいかチェックするの大変！！！」 61
62. Fixtures移行への挑戦 ・チームに導入するメリットデメリットとは？ ・移行コストについて検証が必要 ・どう実現するか？ ・静的解析にトライ ・AI(Opus 4.6)に作業させてみる ・中間的な材料を生成して、変換の精度と確認のしやすさを上げる ・最終判断 62
63. Fixtures移行への挑戦 ・チームに導入するメリットデメリットとは？ ・移行コストについて検証が必要 ・どう実現するか？ ・静的解析にトライ ・AI(Opus 4.6)に作業させてみる ・中間的な材料を生成して、変換の精度と確認のしやすさを上げる ・最終判断 ・メリットよりも移行コストが上回ると判断 63
64. 調査時の失敗談…
65. 調査時の失敗談… https://kaigionrails.org/2026/talks/nissyi-gh/ 65
66. 調査時の失敗談… ・本当に？ ・冒頭で説明した仕組みなら、Fixturesの方が速そう ・検証当時を思い出してみた ・シンプルなmodel specで速くなるかを検証していた ・資料を作りながら再検証してみた 66
67. 調査時の失敗談… ・元々の状態（FactoryBot使用） ・Finished in 1.6 seconds ( les took 4.6 seconds to load) ・Fixtures移行後 ・Finished in 1.33 seconds ( les took 4.93 seconds to load) ・この計測では、テスト時間は短縮。ロード込みの合計はほぼ同じ ・ただし、let̲it̲beで高速化を実施済みだった fi fi 67
68. 調査時の失敗談… ・mintest x Fixtures への移行にも挑戦していた ・この時点ではテストフレームワークも変える検証をしていた ・request spec 数本で検証。3倍ぐらい速くなった ・一部で速くなったからといって、全体が速くなるわけではない 68
69. 調査時の失敗談… ・さまざまな検証を繰り返すうちに、何を確認したいのか曖昧に ・セットアップ、テストデータ生成…切り分けて確認すべきだった 69
70. 調査時の失敗談… 本題に戻ります 70
71. 調査時の失敗談… Fixtures移行はしないと判断 でも、テストは遅いまま… 71
72. Fixtures以外で高速化に挑戦
73. Fixtures以外で高速化に挑戦 ・委員会活動の成果で、いくつかの手法が残されていた ・ボトルネックの特定 ・let̲it̲beの導入範囲の拡大 ・不要な関連レコード生成を削減 73
74. Fixtures以外で高速化に挑戦 ・委員会活動の成果で、いくつかの手法が残されていた ・ボトルネックの特定 ・let̲it̲beの導入範囲の拡大 ・不要な関連レコード生成を削減 74
75. TestProf
76. TestProf https://test-prof.evilmartians.io/ 76
77. Fixtures以外で高速化に挑戦 https://speakerdeck.com/stefafafan/gha-ci-performance-tuning?slide=35 77
78. TestProf ・Rubyのテストを計測・高速化するgem ・遅い原因の調査と、テストの準備処理の効率化を支援する 78
79. TestProf ・ボトルネックの特定に活用 ・Factoryの生成回数・時間を調べる：FactoryProf ・SQLなど、指定したイベントの回数・時間を調べる：EventProf ・DBへの保存が不要な可能性のあるテストを探す： FactoryDoctor 79
80. Fixtures以外で高速化に挑戦 ・委員会活動の成果で、いくつかの手法が残されていた ・ボトルネックの特定 ・→ Factory関連のセットアップがネック ・let̲it̲beの導入範囲の拡大 ・不要な関連レコード生成を削減 80
81. Fixtures以外で高速化に挑戦 ・委員会活動の成果で、いくつかの手法が残されていた ・ボトルネックの特定 ・→ Factory関連のセットアップがネック ・let̲it̲beの導入範囲の拡大 ・不要な関連レコード生成を削減 81
82. let̲it̲be
83. let̲it̲be ・TestProfの一機能 ・example groupで一度準備した値・データを、 配下のexampleで再利用する 83
84. let̲it̲be ・example groupの開始時に データを一度作成し、 各exampleで再利用 ・各exampleでのデータ 作成を省き、準備にかかる 時間を短縮 84
85. let̲it̲be ・メモリ上のRubyオブジェクトの変更が、 次のexampleに残ることがある ・必要に応じて reload: true で同じオブジェクトを DBから再読み込みするか、 re nd: true で新しいオブジェクトとして再取得する fi 85
86. 不要な関連レコード生成を削減
87. 不要な関連レコード生成を削減 ・user に紐づく 関連レコードがたくさん ・不要なレコードを抑制 87
88. 不要な関連レコード生成を削減 https://www.youtube.com/watch?v=n0epZM-lZvw 88
89. 不要な関連レコード生成を削減 すでに利用されていた手法で改善を試みた 89
90. 不要な関連レコード生成を削減 それでもまだ、速くならなかった 90
91. 横断的に使用するリソースを削減したい
92. 横断的に使用するリソースを削減したい ・request specで 生成しがちなuserと 関連リソース群 ・let̲it̲beや関連リソースの 削減では、単一プロセス ごとの改善にとどまる 92
93. スマートバンクのテストは？ メインリポジトリでのテストを題材に話します ・RSpec ・FactoryBot ・system specなし ・並列実行 ・セルフホストランナー上で実行 93
94. 横断的に使用するリソースを削減したい 並列実行でも、共通のリソースをキャッシュできないか？ 94
95. FixtureKit
96. FixtureKit https://github.com/gusto/ xture̲kit fi 96
97. FixtureKit ・初回は、FactoryBotなどで テストデータを作成する ・同じテストデータを DBに入れ直せる INSERT文として保存 ・各テストの実行前に、 そのINSERT文を 実行してデータを用意 97
98. FixtureKit 98
99. FixtureKit ・抱えていた課題 ・request specで頻繁にuser/関連レコードが生成される ・横断的にキャッシュを活用できる基盤を整備 ・user/関連レコードの生成を抑制する ・FactoryBotの既存資産を活かしながらも高速化に貢献 99
100. FixtureKit 100
101. FixtureKit ・TestProfのAnyFixtureでも同様のことが実現できる ・並列化したテストでのキャッシュ共有を実現したい ・検証したリポジトリではMySQLを使用 ・AnyFixtureのregister̲dumpは、MySQL非対応だった ・AnyFixtureは採用見送り 101
102. スマートバンクのCIはどうなったのか？
103. スマートバンクのCIはどうなったのか？ ・nissyi ・let̲it̲be、FixtureKit導入、不要な関連レコード生成を削減 ・test-queue gemの導入 ・yuhi ・不要なテスト実行の削減 ・CIの並列実行数調整 ・MySQLの設定値（innodb̲doublewrite）変更 ・stefafafan ・MySQLの設定値（innodb̲ ush̲log̲at̲trx̲commit, skip-log-bin）変更 ・ohbarye ・YJIT導入 fl 103
104. スマートバンクのCIはどうなったのか？ 104
105. スマートバンクのCIはどうなったのか？ ・nissyi ・Factory setupの負荷を下げる積み重ね ・let̲it̲be、FixtureKit導入、不要な関連レコード生成を削減 ・Yuhi ・CIの並列実行数調整 105
106. スマートバンクのCIはどうなったのか？ 106
107. スマートバンクのCIはどうなったのか？ ・CIの並列実行数の調整を7月末にも検証した ・7月末時点では、実行時間に変換が見られなかった ・8月下旬での検証では、実行時間に大きな変化が見られた 107
108. スマートバンクのCIはどうなったのか？ 108
109. スマートバンクのCIはどうなったのか？ 109
110. スマートバンクのCIはどうなったのか？ 2月時点と比較して… テストケース数は50%増加 実行時間はベースラインを維持 110
111. スマートバンクのCIはどうなったのか？ 高速化はできた👏 111
112. スマートバンクのCIはどうなったのか？ 112
113. スマートバンクのCIはどうなったのか？ 残っている課題… セルフホストランナーの負荷が高まると、実行時間が不安定に 113
114. スマートバンクのCIはどうなったのか？ これから改善していきます💪 114
115. まとめ
116. まとめ ・Fixturesへの置き換え検証に挑戦 ・速くなったテストも、速くならないテストもあった ・移行・保守・チーム運用のコストも含めて判断する ・今回は移行を見送った ・FactoryBotを使い続けても、改善できる手段はある ・まず計測して、自分たちのボトルネックに合う手段を選ぶ 116
117. まとめ 手段 効果が期待できる場面 保守・導入で考えること FactoryBotの見直し 不要な生成や関連が多い 既存の書き方を活かして改善できる let̲it̲be 同じデータをexampleごとに 作り直している 共有範囲と状態の持ち越しに注意 Rails Fixtures 共通データをYAMLで 投入・再利用したい YAML移行、ラベル運用、 データ整合性の管理 FixtureKit Rubyで定義した共通データの生成を 繰り返している 生成と復元のコスト、 キャッシュの扱いを検証 117
118. まとめ 「FactoryBotをやめればRSpecは速くなるのか？」 118
119. まとめ 「FactoryBotをやめれば、速くなる場合はある」 119
120. まとめ 「FactoryBotをやめれば、速くなる場合はある」 「でも、使い続けながら速くする方法もある」 120
121. 最後に宣伝を スマートバンク社員の登壇紹介(Day 2) Magenta Hall 11:05 ~ 11:20 Lime Hall 13:55 ~ 14:25 121
122. FactoryBotをやめれば RSpecは速くなるのか？ 2026/10/16 Yuta Onishi 122