Go1.25新機能 testing/synctest で高速＆確実な並行テストを実現する方法

Go Conference 2025での登壇資料です

一部スライドでアニメーションを使用しているので、見づらい場合は下記のGoogle Slideから閲覧をお願いします
https://docs.google.com/presentation/d/1nCysE_J4WpRUwvDQSAzZbtFFCgCWAZL1tayBVfh79iQ/edit?slide=id.p1#slide=id.p1

Transcript

1. 2025.09.28 presented by Pana Go 1.25新機能 testing/synctest で高速 ＆確実な並行テストを実現する方法 Go Conference 2025
2. ⾃⼰紹介
3. ⾃⼰紹介 ‧名前: Pana（Kanata Miyahana） ‧年齢: 29 ‧所属: 株式会社カナリー ‧役割: テクニカルリードエンジニア（いわゆるテックリード的な⽴ち位置） ‧業務: 不動産マーケットプレイス「カナリー」のバックエンド領域の開発
4. zennでの発信に⼒を⼊れています 💪
5. BtoC/BtoB両軸でプロダクトを展開 *アプリ評価: iOSおよびGooglePlayにおける主要部屋探しアプリのユーザー評価(2022年11⽉data.ai社調査)。 ‧BtoC 不動産マーケットプレイス｢カナリー｣ ‧アプリ版 累計DL数 500万 (Web版もあります！) ‧カテゴリ内ユーザー評価No.1(App Store ★4.8)* ‧TVCMも全国で放映 ‧BtoB 不動産仲会社向けSaaS｢カナリークラウド｣ ‧累計利⽤者数 200万⼈を突破 ‧後発ながら、全国の地⽅⼤⼿企業様を軸に急成⻑
6. 新規も含め、様々な事業領域‧フェーズでプロダクトを展開 BtoC BtoB 0 → 1 10 → 100 1 → 10 100 → … 現在、複数の 新規プロダクトを 開発中
7. Go 1.25リリース🎉
8. Go 1.25 のリリースサマリ 今回は Go 1.25で標準パッケージになった testing/synctest パッケージを紹介！ • go vet に新しく2つのアナライザーが追加 • 実験的なガベージコレクタの導⼊ • encoding/json/v2 が実験的に導⼊ • testing/synctest が標準パッケージに • container-aware な GOMAXPROCS の導⼊ • etc...
9. アウトライン 1. 背景と課題提起 2. API紹介 a. Run と Test 3. 実験コードを交えての解説 a. GoDoc を読む b. Run / Test がそれぞれどのような役割があるのか 4. Go クイズ！ 5. 弊社での実際の活⽤例 6. Go 1.24からの変更点 7. 今後の展望 8. API の内部実装（時間があれば） testing/synctest を完全理解する！
10. 背景と課題提起
11. “⾮同期的なテスト” は “難しい” 😞
12. 同期的なテスト ⾮同期なテスト 簡単な例で考えてみる
13. 実⾏してみると... TestSumSync は通るが、TestSumAsync が落ちる。。。
14. テストが落ちないようにしようとすると。。。 実⾏してみる 約0.7秒くらいかかるがテストは落ちない 👍
15. テスト時間を短くしようとすると。。。 実⾏してみる 約0.2秒くらいで終わるようになったが、5回中4回落ちる
16. Q. “⾮同期なテスト”はなぜ “難しい”？
17. A. テスト時間を短くしつつ、テスト を落ちないようにすることの両⽴ が難しい
18. つまり... • ⾮同期なテストは難しい ◦ 難しさ = テスト時間を短くしつつ、テストを落ちないようにすること • ポイント ◦ ⾮同期な処理が終わることを担保したのちに、チェックを実⾏する必 要があること ◦ 処理を待つ時間は何もすることがなく無駄な時間なので、できるだけ 短くしたいということ testing/synctest パッケージで解決 💪
19. API紹介
20. まずは GoDoc をみてみる 解決したいこと 対応する API ⾮同期な処理が終わることを担保したのちに、チェックを実 ⾏する必要があること Wait 処理を待つ時間は何もすることがなく無駄な時間なので、で きるだけ短くしたいということ Test
21. まずは GoDoc をみてみる “bubble” と “durably blocked" が重要なコンセプト 💡
22. 実験1: 簡単なキャッシュ
23. 実験1: 簡単なキャッシュ（実装コード） ‧Set とGet のみ ‧Set が呼ばれた時に setTime = time.Now() が実⾏される ‧Get が呼ばれた時、TTL 経過していたら 空⽂字、そうでない場合は c.value が返さ れる
24. 実験1: 簡単なキャッシュ（テストコード） テストの実⾏に1秒以上かかる 😢 実⾏してみる
25. 実験1: 簡単なキャッシュ（テストコード） Test 関数で Wrap すると、約0.15秒でテストが終わる 🎉 実⾏してみる
26. synctest.Test の GoDoc をみてみる
27. synctest.Test の GoDoc をみてみる（⼀部翻訳） 1. Test は関数 f を bubble の中で実⾏する 2. Test は bubble の中のすべてのゴルーチンが終了するまで待つ 3. bubble の中のすべてのゴルーチンが deadlock したら、テストが落ちる 4. Test は bubble の中で呼んではならない 5. f の引数に渡される *testing.T は以下の性質を持つ a. T.Cleanup は Test が終了する直前に bubble の中で実⾏される b. T.Context は bubble に紐づく Done チャネルを持つ context.Context を返す c. T.Run, T.Paralle, T.Deadline は呼んではならない 時刻に関する記述がないが、、、？ 🤔
28. https://pkg.go.dev/testing/synctest#Time を⼀部抜粋 1. bubble の中では time パッケージは fake clock を使⽤する 2. bubble ごとに clock は独⽴している 3. 初期時刻は UTC 2000-01-01 で設定されている 4. すべてのゴルーチンが durably block になったら、bubble 内の時刻が進む 5. bubble のゴルーチンが終了したら、時刻が進まなくなる
29. https://pkg.go.dev/testing/synctest#Time を⼀部抜粋 3, 4について検証してみる 💡 1. bubble の中では time パッケージは fake clock を使⽤する 2. bubble ごとに clock は独⽴している 3. 初期時刻は UTC 2000-01-01 で設定されている 4. すべてのゴルーチンが durably block になったら、bubble 内の時刻が進む 5. bubble のゴルーチンが終了したら、時刻が進まなくなる
30. 「初期時間は UTC 2000-01-01 で設定されている」を検証！ time.Sleep の前後で時刻が進んでいる！ 実⾏してみる
31. https://pkg.go.dev/testing/synctest#Blocking を⼀部抜粋 1. bubble の中のゴルーチンは、⾃⾝が block されている状態で同じ bubble 中の他のゴルーチンによってのみ unblock される場合に “durably block” になる 2. 以下の操作はゴルーチンを “durably block” する a. time.Sleep b. etc... 3. 以下の操作はゴルーチンを “durably block” しない a. sync.Mutex or sync.RWMutex b. etc...
32. 先ほどのテストに戻って考える 2000 01-01-01 00:00:00 2000 01-01-01 00:00:01 durably block 時刻が 進む
33. 時刻が進む条件をおさらい 1. bubble 内は fake clock を⽤いる 2. 初期時刻は UTC 2000-01-01 で設定されている 3. すべてのゴルーチンが durably block になったら、bubble 内の時刻が進む 4. time.Sleep はゴルーチンを durably block する 1つしかゴルーチンがないので、time.Sleep で時刻が進む
34. 実験1: 簡単なキャッシュのまとめ もうちょっと実⽤的な例を考えてみる ‧今回の実験で分かったこと ‧Test を使えばテストにかかる時間を短縮できる ‧Test の挙動（⼀部のみ） ‧ここで疑問 🤔 ‧「別にTTLを1秒にしなくても、1マイクロ秒にすればいいやん」 → その通りです！今回の実装の場合 testing/synctest パッケージは不要 → なぜなら、そもそもの実装が同期的に実⾏されるから
35. 実験2: 簡単なキャッシュv2
36. 実験2: 簡単なキャッシュv2（実装コード） ‧Set が呼ばれた時に、別のゴルーチン で c.value を空⽂字に更新する ‧「何かの関数を呼んだ際に、別のゴ ルーチンが作られる」という挙動を具 体化した1つの例として考えてみる
37. 実験2: 簡単なキャッシュv2（テストコード） 10回中3回落ちた = ランダムで落ちるテストになっている 😢 10回実⾏してみる 先ほどと同じテスト！
38. なぜランダムで落ちるのか？ 「Get」と「c.value = “”」のどちらが先に実 ⾏されるか不明 = ランダムで落ちる原因 (testing/synctest の仕様) bubble の中のすべてのゴルーチンが durably block されたら時刻が進む durably block durably block 時刻が 進む
39. 実験2: 簡単なキャッシュv2（テストコード） 落ちなくなった 🎉 直感的には「ゴルーチンの終了を待つ」挙動だが...？ 10回実⾏してみる
40. synctest.Wait のGoDocをみてみる
41. synctest.Wait のGoDocをみてみる（⼀部翻訳） 1. Wait は bubble 内の現在のゴルーチン以外のすべてのゴルーチンが durably block されるまで block する 2. bubble の外から Wait を呼んではいけない 3. 同じ bubble 内で複数のゴルーチンから Wait を並⾏に呼んではいけない 「ゴルーチンの終了を待つ」とは書かれていない！ 「durably block されるまで block する」と書かれている！
42. synctest.Wait を呼んだ時の挙動 1. Wait が呼ばれた時、右のゴルーチンは実 ⾏中だと仮定 2. 右のゴルーチンが durably block になる まで待つ 3. durably block になることなく、右のゴ ルーチンが終了 4. Wait は右のゴルーチンを気にする必要が なくなって unblock 5. 左のゴルーチンの処理が進む = Get の処理 が呼ばれる (testing/synctest の仕様) bubble の中のすべてのゴルーチンが durably block されたら時刻が進む
43. より “厳密な” テストコードを書いてみる 1000回実⾏してみる 問題なし 👏
44. 処理の流れをより深ぼってみる Q. どこまで時刻が進むのか？ すべてのゴルーチンが durably block になったら、bubble 内の時刻が進む Q. 時刻が進んだゴルーチンの状態は？
45. 再び GoDoc を⾒てみる（⼀部抜粋） When every goroutine in a bubble is durably blocked: - Wait returns, if it has been called. - Otherwise, time advances to the next time that will unblock at least one goroutine, if there is such a time and the root goroutine of the bubble has not exited. - Otherwise, there is a deadlock and Test panics.
46. 再び GoDoc を⾒てみる（⼀部抜粋） bubble 内のすべてのゴルーチンが durably block されている場合： - Wait が呼び出されている場合、Waitが返る。 - そうでない場合、少なくとも1つのゴルーチンが unblock される次の時刻まで 時間が進む（そのような時刻が存在し、かつ bubble のルートゴルーチンが終了 していない場合）。 - そうでない場合、deadlock が発⽣しテストがパニックする。 少なくとも1つのゴルーチンが unblock するまで時刻が進む
47. Q. どこまで時刻が進むのか？ テストの time.Sleep の⽅が短い → 先にテストのゴルーチンが unblock Q. どこまで時刻が進むのか？ A. ttl - time.Nanosecond まで進む
48. Q. 時刻が進んだゴルーチンの状態は？
49. Q. 時刻が進んだゴルーチンの状態は？ Q. 時刻が進んだゴルーチンの状態は？ A. durably block のままと考えられる
50. ここまで分かったことをおさらい！ 1. Test は渡された関数 f を bubble 内で実⾏する 2. bubble 内の時刻は UTC 2000-01-01 からスタートする（fake clock） 3. すべてのゴルーチンが durably block になったら、bubble 内の時刻が進む 4. Wait は bubble 内の現在のゴルーチン以外のすべてのゴルーチンが durably block されるまで block する 5. time.Sleep はゴルーチンを durably block する 6. （他にも durably block の条件があるが割愛） “bubble” と “durably block” が⼤事！
51. Go クイズ！
52. Go クイズ！ Q1. 下記で出⼒される時刻はどうなるか？ 正解は C A. 時刻は出⼒されない B. テストを実⾏した時の時刻 C. 2000-01-01 00:00:00 (UTC) (Test の仕様) Test は bubble の中のすべてのゴルーチンが終了するまで待つ
53. Go クイズ！ Q2. time.Sleep を外すとどうなるか？ 正解は A A. テストが落ちる B. ランダムで落ちるテストになる C. テストは落ちない (Wait の仕様) Wait は現在の bubble 内の現在のゴルーチン以外のすべてのゴルー チンが durably block されるまで block する → Set で作成されたゴルーチンは durably block されているので、 即時にテストの処理が進む
54. Go クイズ！ Q3. 落ちる原因が分からない！と後輩エンジニアが尋ねてきた！ 正解は C A. ゴルーチンの前に1秒待つ B. 1つ⽬の Wait の前に1秒待つ C. 2つ⽬の Wait の前に1秒待つ
55. どうやったら落ちないようになるか考えてみる
56. どうやったら落ちないようになるか考えてみる
57. 正解のコード
58. 弊社での活⽤事例
59. 弊社の物件データの処理 • 物件データは CSV 形式で FTP サーバーにアップロードされる • 弊社のシステムから FTP サーバーの CSV ファイルを取得する • CSV ファイルを加⼯してデータベースに保存
60. 弊社の物件データの処理
61. どういうテストが書かれていたか？ FTPへの接続タイムアウト 操作ごとのタイムアウト
62. 改善した結果どうなったか？ テストの種類 Before (秒) After (秒) FTPへの接続タイム アウト 60.221 0.256 操作ごとのタイムアウ ト 20.369 0.417 約80秒のテスト時間短縮に成功 🎉
63. ポジティブな反応ももらえた
64. 感想 • 良かった点 👍 ◦ 1, 2時間ぐらいで実装できた ◦ ⾼速化もできた 元々のテストは残しつつ、testing/synctest のテストを導⼊！ • 難しかった点 👎 ◦ 元々のモックサーバーがそのまま使えなかった ◦ テストの場合のみダミーの挙動をするような実装になった
65. Go 1.24 からの変更点
66. 主な変更点 Testing Time (and other asynchronicities) からいくつかを抜粋して紹介 1. Run から Test への変更 2. bubble のルートゴルーチンが終了したら時刻の進⾏を停⽌ 3. durably が該当しないケースを削除 4. スタックトレースの改善 5. 同時に発⽣するイベントをランダムに
67. 主な変更点 Testing Time (and other asynchronicities) からいくつかを抜粋して紹介 1. Run から Test への変更 2. bubble のルートゴルーチンが終了したら時刻の進⾏を停⽌ 3. durably が該当しないケースを削除 4. スタックトレースの改善 5. 同時に発⽣するイベントをランダムに 1, 2, 4を解説
68. 変更点1: Run から Test への変更 https://github.com/golang/go/issues/73567 で議論 • bubble の中で呼び出された t.Cleanup が bubble の外側で実⾏される → bubble 内のゴルーチンを close する時に問題になる可能性 • t.Context で呼び出される context.Context が bubble と紐づかない Done チャネルを持つ → bubble の中で使いたい context.Context にならない可能性 引数として *testing.T を受け取るように Test が実装された
69. 変更点1: Run から Test への変更 t.Cleanup が bubble の外で実⾏されている！ 実⾏してみる
70. 変更点1: Run から Test への変更 t.Cleanup が Test (bubble) の中で実⾏されている！ 実⾏してみる
71. 余談 Q. *testing.B については？ → bubble を作成して維持すること⾃体がパフォーマンスへの影響があるので導 ⼊は考えられていない Q. *testing.F については？ → synctest.Fuzz を持った⽅が良いかもしれないが、今後容易に実装できるので 現時点では容易に意思決定しなくて良い より詳細を知りたい⽅は https://github.com/golang/go/issues/73567 を参照
72. 変更点2: bubble のルートゴルーチンが終了したら時刻の進⾏を停⽌ Testing Time (and other asynchronicities) では以下のように述べられている This turned out to be very confusing when a long-lived goroutine never returned, such as a goroutine reading forever from a time.Ticker. We now stop advancing time when a bubble’s root goroutine returns. If the bubble is blocked waiting for time to advance, this results in a deadlock and a panic which can be analyzed.
73. 変更点2: bubble のルートゴルーチンが終了したら時刻の進⾏を停⽌ Testing Time (and other asynchronicities) では以下のように述べられている ⻑寿命のゴルーチンが永遠に返らない場合（例：time.Ticker から無限に読み取 るゴルーチン）、これは⾮常に混乱を招くことが判明しました。現在では、 bubble のルートゴルーチンが返った時点で時間の進⾏を停⽌します。もし bubble が時間の進⾏待ちで block されている場合、これは deadlock と panic を引き起こし、分析が可能となります。
74. 変更点2: bubble のルートゴルーチンが終了したら時刻の進⾏を停⽌ 実⾏してみる 永遠にテストが終わらない
75. 変更点2: bubble のルートゴルーチンが終了したら時刻の進⾏を停⽌ 実⾏してみる deadlock として検知される！
76. 変更点4: スタックトレースの改善 https://github.com/golang/go/issues/70911 で議論 → panic を引き起こしたゴルーチン + bubble 内のゴルーチンのスタックトレース
77. 変更点4: スタックトレースの改善 https://github.com/golang/go/issues/70911 で議論 → panic を引き起こしたゴルーチン + bubble 内のゴルーチンのスタックトレー ス
78. 今後の展望は？
79. Testing Time (and other asynchronicities) のブログから引⽤ Aside from the inevitable bug fixes, we don’t currently expect any major changes to it in the future. Of course, with wider adoption it is always possible that we’ll discover something that needs doing. 避けられないバグ修正を除けば、現時点では将来的に大きな変更は予定し ていません。もちろん、適用範囲が広がれば、対応が必要な問題が見つか る可能性は常にあります。 ⼤きな変更はないと考えて良さそう 💡
80. まとめ
81. 今回の発表のまとめ 1. testing/synctest を使うと⾮同期なテストにかかる時間を短縮できる 2. synctest.Test の中のすべてのゴルーチンが durably block されてから時刻が進む 3. synctest.Wait はゴルーチンの終了を待つわけではない a. durably block になるのを待つ 4. GoDoc 読むの⼤切 a. 直感的なコードの挙動と実際の挙動が違っていた 5. 実際に導⼊してみたが、時間をかけることなくシンプルな実装で導⼊できた みなさんもぜひ使ってみてください！😆
82. 参考⽂献 1. https://pkg.go.dev/testing/synctest 2. https://go.dev/blog/testing-time 3. testing/synctest: new package for testing concurrent code 4. testing/synctest: replace Run with Test 5. proposal: testing/synctest: create bubbles with Start rather than Run 6. Testing Time (and other asynchronous code) - Damien Neil | GopherCon EU 2025
83. ありがとうございました