メールやSlack通知をトリガーにした非同期APIテスト基盤を作ってみた / async-test-platform-for-automated-testing

ユーザーへのフィードバックがメールやSlack通知である機能のテストをしたいと思ったことがありませんか？私はあります。
例えば「決裁権者への決済の催促」「大量のデータが入っているCSVのダウンロードリンクが後からくる」「とても重要な管理者にだけ届くべき通知」などです。
今回はそれらをテストするために1週間でテストするための基盤を安いコストで作ってみました！

Transcript

1. メールやSlack通知をトリガーにした非同期APIテスト自動化 基盤について 2025.10 JaSST'25 Kyushu 前夜祭
2. 自己紹介 Name: bun913 / ぶん（さん） Job: SDET (Software Development Engineer in Test) Previous Job 開発者 AWSに関する ソリューションアーキテクト Hobby 子どもと遊ぶこと 自分と自分の好きな人が喜ぶツール作り 英語学習 2
3. 最近弊チームでは 3
4. APIテスト自動化に力を入れています 4
5. なぜか？ UI E2Eテストに比べて 早い 壊れにくい ユニットテストに比べて ビジネスロジックをより高いレベルで検証できる 連携システムなどよりリアルに近い依存を含めた検証ができる 5
6. まだデータは少ないですが テストを実行し始めてから6ヶ月程度の間に 数十件の自動テスト失敗があった（同じ原因のRetry含まない） 記録しているもののうち Positiveな失敗:Negativeな失敗 = 4:1 程度 Negativeな失敗もテスト実装者（私）の考慮不足がほとんど 6
7. そんなAPIテスト自動化基盤の構成（以前） 7
8. Playwright ・Playwright でテストを実⾏ ・テスト結果をテスト管理ツールに保存 Target API 1: Request TestRail 2: Feedback 3: Store Test Result 8
9. 非常にシンプル 9
10. ただし、自動テスト化できていない機能があった ユーザーの操作に対するフィードバックが非同期なもの かつ、フィードバックがメールやSlackに飛んでくるもの 大量のデータを扱う処理で、後からメールでダウンロードURLが来たり 特定の管理者に向けて、重要なメッセージが飛んだり ワークフローの承認者に対して、承認依頼の通知が飛んだり などなど 10
11. 一瞬考えたこと 非同期で結果がくると言っても大体の場合は1分以内には届く では、テスト実行後に素直に待ってから確認すれば？ すぐに筋が悪いと気づく 時間経過を待つと、いかにも壊れやすいテストになりそう シンプルにCIで実行するテストの時間が伸びる テスト環境の制限で、いろんな条件で遅延が発生する可能性がある 11
12. その時電流走る 12
13. イベント駆動で安い仕組み作るか 13
14. Playwright ・Playwright でテストを実⾏ ・期待する結果を外部のDB に保存しておく Target Sysgtem 1: Request 2: Save Expected Result DynaomoDB User 3: Feedback mail Slack 4: Forward to Slack 5: Invoke Slack App 6: Get Expected Result Slack ・期待値と実際値を⽐較 ・結果をフィードバック TestRail API Gateway Lambda こういうピタゴラスイッチを作ってみました 14
15. 基本的な流れ Playwright で ターゲットのAPIを順次実行 目的のビジネスロジックを再現するようにAPIを呼ぶ ターゲットのシステムから メール・Slack通知が飛ぶ メールはGmailの転送機能で特定のSlackチャンネルに転送 Slack AppでイベントをキャッチしてLambdaを呼ぶ Lambda で期待値と実際の結果を比較する Assertion して、失敗ならSlackでメンションされる 成功ならメッセージに がつく 15
16. メール通知だけでなく Slack通知も同様にテス トしています 16
17. 期待値と実際の結果が違う時のイメージ 17
18. 期待値と実際の結果が合っている時のイメージ 18
19. 検証用のソースコードも含めてZennで公開しています 19
20. 3週間くらい回してみて 基盤が壊れることは今のところないです メールやSlackの通知が届くとちゃんとテストが動いている ステージングリリースのたびに自動で動いている安心感 手動だと漏れがちな部分を自動化できて嬉しい 20
21. こだわりポイント 安い イベントドリブンなので、常時動くサービスより安価 DB自体も普段の管理がほぼ不要な DynamoDBを採用 DBの不要なレコードも勝手に消える仕組みを採用（TTL） インフラの運用負荷がほぼ不要なサービスで完結 一度デプロイすれば ランタイム（言語）のアップデート以外はほぼメンテナンス不 要 応用・拡張性が高い インフラもコードで管理しているため他のシステムへの拡張が楽 Webhookで飛ばされるイベントを受け取る仕組みにも応用可能 21
22. できないこと 通知自体が届かないことは検知できない タイムアウトを設定することも技術的には可能だが、テスト環境の特性上あまり現 実的ではない 通知が届くこと自体はモニタリングの責務の範囲と考えるべき SREチームや開発チームと話して、できること・してほしいことを整理しよう 22
23. おまけ（自動APIテストが充実してきてからの 趣味） 23
24. 開発者に言わせる 24
25. まとめ 非同期でメールやSlackにフィードバックが飛ぶ機能に対して自動でテストを回す仕組み を作った 元AWSエンジニアとしての知見を活かして、1週間で基盤作成・テストコード作成・自 動化まで完了した できないことがあるので、モニタリングとの責務ははっきりしておくべき 通知自体が来ないことを検知する仕組みは確認しておこう 25
26. Thank you! 26