外部連携の統合テストをCI/CDに載せるには ── ステートフルモックとシナリオ駆動が現場にもたらす意味
外部サービスとの連携が当たり前になった現代のシステム開発において、「統合テストをCI/CDに組み込む」という課題は多くの開発現場で積み残されたままになっている。このセッションはその核心に踏み込んだ実践報告だ。
出典: 【クラウドネイティブ会議】外部連携を含む統合テストをどう自動化するか ～ステートフルモックとシナリオ駆動の実践～
要点 (事実のみ)
- 日立製作所OSSソリューションセンタの蛭田哲大氏が、認証認可OSS「Keycloak」を用いたシステムを題材に、統合テスト自動化の取り組みを発表した
- 既存のモックサーバーはステートレスなRequest/Responseモデルが主流で、認可コードやアクセストークンを複数リクエスト間で引き継ぐOIDCの認可コードグラントフローを再現できないという課題を提起した
- 解決策として「ステートフルモック（状態保持・状態遷移の再現）」「リクエスト送信（モック自身が外部にリクエストを送信）」「シナリオ駆動（YAML定義による宣言的テスト記述）」の3つの柱でモックをJavaで再設計した
- YAMLによるシナリオ定義は生成AIとの相性が良く、自然言語の指示から数分でYAMLとテストコード（SelenideとJUnit 5）を生成できることをデモで示した
- 実行環境はDockerコンテナ化されており、Docker Composeのワンコマンドで統合テスト一式が起動・実行できる構成になっている
高畑 拓海の見解
このセッションで最も刺さったのは、「統合テストは設計次第でCI/CDに載せることができる」という蛭田氏の結論だ。現場で統合テストが自動化されないまま放置される理由として、「外部環境の制御が難しい」「スケジュール調整が必要」「API課金がある」といった言い訳はよく耳にする。しかし本質的な原因は、モックの設計がステートレスなまま止まっていることにある、という指摘は的確だと感じた。
私が担当してきた案件でも、外部認証基盤やSaaSとの連携部分は「とりあえず手動で確認する」という運用になりがちだった。その結果、リリース前の確認工数が積み上がり、CI/CDの恩恵を受けられる範囲が限られてしまう。状態を持てるモックがあれば、その制約は大きく変わる。
一方で、実務に落とす際に気になる点もある。YAMLによるシナリオ定義は「変更に対応しやすくする」という狙いで設計されているが、外部APIの仕様変更が頻繁に起きる案件では、YAMLの保守がそのまま運用負荷になる可能性がある。誰がシナリオを更新し、どのタイミングでレビューするのかを決めておかないと、テストシナリオが実態から乖離するリスクがある。生成AIでYAMLを高速生成できても、「正しいシナリオかどうかの判断」は人間が担う必要があるため、レビュー体制を先に整備しておくことが重要だと思う。
まずは認証認可のような「ステートフルな通信が避けられない箇所」に絞って導入し、チームで運用できる状態を確かめながら対象を広げていく進め方が現実的ではないだろうか。
(編集レンズ: 現場・運用目線 / チーム再現性目線)
