分岐するマルチステップAPIワークフローのテスト方法——チェーンだけでなく

Rui Li
分岐するマルチステップAPIワークフローのテスト方法——チェーンだけでなく（カバー画像）

単純なAPIチェーンは線形です。リソースを作成し、返されるIDを使用し、読み戻し、更新し、削除します。実際のワークフローの多くは線形ではありません。レスポンスが返ってきて、その内容によって、単一の予測可能な次のステップではなく、いくつかの異なるフォローアップリクエストのうちの1つが発火します。この種のワークフローをテストするには、1つの呼び出しから次の呼び出しへIDを渡す以上のことが必要です。

分岐ワークフローが実際に現れる場所

APIの次のステップが、前の呼び出しの成功可否ではなく、前のレスポンスの値に依存する場合、常に分岐が発生します。

支払い認証は即時承認か追加認証要求のいずれかを返し、クライアントの次の呼び出しはどちらを受け取るかによって完全に異なります。請求の送信は自動承認か手動レビューへの振り分けのいずれかのステータスを返し、フォローアップとしてレビュー割り当てエンドポイントへの呼び出しが発生するのは、そのうちの一方のパスのみです。ファイルのアップロードは処理の成功結果か、個別の問題点一覧を含むバリデーションエラーのいずれかを返し、修正エンドポイントへのフォローアップ呼び出しが発生するのはエラーの場合のみです。

これらのすべてにおいて、静的なIDを次のステップへ渡すだけのテストでは、ワークフローの実際の複雑さを見逃してしまいます。重要な挙動は、どのパスが選択されるか、そして各パスが正しく動作するかどうかにあり、IDが一つの呼び出しから次の呼び出しへ引き継がれたかどうかではありません。

なぜ直線的なチェーンテストではこれを見逃すのか

シーケンス内の単一の期待パスを前提に構築されたテストは、そのシーケンスにパスが一つしかない限りは正常に機能します。しかし、レスポンスが複数の方法で次のステップを決定しうる場合、特定の誰かが思いついたパスだけをテストしても、他のすべての分岐は完全に未検証のまま残ります。

これは見かけ以上に重大な問題です。なぜなら、未テストの分岐こそが最も重要なケースであることが多いからです。すべてが承認され、何もフラグが立たないハッピーパスは、通常の利用や通常の手動テストを通じて常に実行される傾向があります。一方、特定の条件下でのみ発火する分岐、つまり閾値を超えた金額、フラグが立ったパターン、バリデーションの失敗などは、誰も偶然にトリガーすることがありません。つまり、それはまだ誰にも発見されていないバグが潜んでいる可能性が最も高い部分でもあります。

実際に何がトリガーとなるかを観察することで分岐をテストする

分岐ワークフローを網羅するには、どの条件がワークフローを各パスへ導くかを理解し、通常のテストが偶然すべての分岐をカバーすることを期待するのではなく、各条件を意図的に実行する必要があります。

TestSpriteのBackend Testing 2.0は、フローの静的な記述ではなく、観察されたAPIの挙動からこれを構築します。探索エージェントが決定境界の両側にある値でリクエストを送信すると、それぞれがどのレスポンスパスをトリガーするかを観察し、パスが一つしかないと仮定するのではなく、両方を対象としたテストカバレッジを構築します。

他の検証ツールはコードを読んで推測します。TestSpriteはあなたのアプリを開いて実際に使います。

動的変数は、各実際のレスポンスからキャプチャした値を、そのレスポンスが実際に取った分岐に対応するダウンストリームリクエストへと引き継ぎます。これにより、自動承認されたクレームは自動承認パスでテストされ、フラグが立ったクレームはレビューパスでテストされ、各分岐はその特定のパスで発生すべき挙動に基づいて検証されます。

シナリオ：保険プラットフォームの請求ルーティングロジック

保険商品向けの請求処理プラットフォームを開発するチームには、請求金額に応じて2つのパスのいずれかを実行するAPIがあります。設定された閾値未満の請求は自動承認されて即座に支払いキューに追加されますが、閾値を超えた請求は手動レビューキューに振り分けられ、支払い前にアジャスターの対応が必要です。

AIコーディングエージェントが、より大規模な請求カテゴリの更新の一環として閾値ロジックを変更しました。チームは手動で特定のパスだけを確認するのではなく、TestSpriteをライブAPIに対して実行します。

探索エージェントは、閾値を明らかに下回るもの、明らかに上回るもの、そして境界値の両側に意図的に近づけたいくつかの金額で請求を送信します。ほとんどは期待通りに動作しましたが、一つ例外がありました。閾値ちょうどの金額で送信された請求が、レビューへ振り分けられるべきところを自動承認されていました。更新された比較ロジックが、元の仕様が以下（less-than-or-equal）を求めていたところに厳密な未満（strict less-than）チェックを使用していたためです。

これは、通常のテストではほとんど発見できない境界バグです。なぜなら、請求金額が偶然にも閾値ちょうどになることは稀だからです。テストが境界条件を意図的に実行したことで、このバグが表面化しました。

失敗レポートには請求金額、期待されたパス、および実際に取られたパスが明記されます。コーディングエージェントが比較演算子を修正し、TestSpriteが境界値を含む全範囲の請求を再実行して、両方のパスが正しくルーティングされることを確認します。

すべての分岐が、よくあるものだけでなく、それぞれ専用のチェックを受けられるようにする

ここから導かれる実践的な習慣は、「ワークフローは正常に動作するか」という単一の問いではなく、ワークフローの各分岐を独立して検証すべき対象として扱うことです。レスポンスが次の動作を複数の方法で決定するAPIに対しては、可能なパスそれぞれを明示的に特定し、ワークフローの広範なカバレッジがすべての分岐を公平にテストしたと仮定するのではなく、各パスがテスト中に実行されることを確認することが重要です。

TestSprite Webポータルを通じてスケジュール設定されたリグレッションの実行が、セッション内チェックを超えた価値を提供するのはここです。条件や閾値が時間とともに変化するにつれて、ワークフローの分岐が微妙に変化する可能性があり、定期的なチェックによって、機能が最初にリリースされて以来意図的にテストされていない分岐のドリフトを検知できます。

まとめ

複数の可能な次のステップを持つワークフローには、呼び出し間でIDを引き渡すだけのテスト以上のものが必要です。どのパスにリクエストが進むかを決定する境界条件を含め、各分岐をそれ自体の価値ある検証対象として扱う必要があります。

TestSpriteは、単一の想定パスではなく、分岐全体にわたる観察されたAPIの挙動からカバレッジを構築し、特定の条件が意図的にテストされた場合にのみ現れる境界バグを検知します。

TestSpriteで分岐APIワークフローをテストし、誰も思い出してチェックしないパスを未検証のまま放置するのをやめましょう。