APIモック活用事例：APIモックを使うべき時と理由

ほとんどのチームはAPIのモック方法を知っています。しかし、それが実際に役立つ時と、単にメンテナンスすべき層を増やすだけになる時の明確な答えを持っているチームは少ないです。適切なタイミングで利用するモックは、実際のボトルネックを取り除きます。習慣的に作成するモックは、現実から乖離し、静かに嘘をつく別のものになってしまいます。

この記事では、モックの「方法」は省略し、「いつ」使うべきかに焦点を当てます。各セクションでは、モックがその価値を発揮する具体的な状況、すなわち、未完成のバックエンドに対する構築、エラーパスのテスト、不安定なサードパーティサービスの代用、デモの実行、CIの安定化について説明します。これはチュートリアルではなく、意思決定の助けとしてお読みください。

フロントエンドとバックエンドの並行開発

これは典型的なケースです。フロントエンドチームは、バックエンドチームがまだ構築していないエンドポイントを必要としています。モックがなければ、フロントエンドは待機するか、実際のサービスとの最初の接続で壊れるような推測に基づいてコードを記述することになります。

モックは依存関係を解消します。両チームはまず契約、通常はOpenAPIドキュメントとして合意します。フロントエンドはその契約から生成されたモックに対して構築し、バックエンドは実際のものを実装します。バックエンドがデプロイされたら、フロントエンドはベースURLを切り替えるだけで、両側が契約を尊重していれば、他に変更はありません。

合意が重要な部分です。フロントエンド単独で考案されたモックは、単に一方のチームの仮定をコード化したに過ぎません。共有された仕様から派生したモックは、両チームを連携させ、これはAPI契約テストの背後にある原則と同じです。並行作業を妨げないためにモックを使用しますが、それは両側が承認した契約に対してのみにしてください。

そのメリットはプロジェクト全体にわたって増幅されます。バックエンドでブロックされることのないフロントエンドチームは、独自のスケジュールで機能をリリースします。中途半端なエンドポイントのために呼び出されることのないバックエンドチームは、集中力を保てます。デザイナーやプロダクトマネージャーは、何週間も早くクリック可能なビルドを手に入れ、それに対して反応できます。これらのどれも、実際のサービスが存在することを必要としません。唯一の継続的なコストは、契約が進化するにつれてモックを契約と同期させ続けることですが、モックが手書きではなく仕様から生成されていれば、このコストは低く抑えられます。

オンデマンドでトリガーできないエラーパスのテスト

健全なAPIは200を返します。それが問題なのです。クライアントコードは429、500、503、不正な形式のボディ、タイムアウトも処理しなければなりませんが、正常に動作しているサーバーはテストが要求してもこれらを生成しません。

モックは、コマンドに応じてこれらを生成します。あるリクエストには500を返し、別のリクエストにはRetry-Afterヘッダー付きで429を返し、そして3つ目のリクエストには意図的な遅延の後でボディが届くように設定します。そして、リトライロジック、バックオフ、タイムアウト処理がすべて正しく動作することを確認します。

これは、チームが最も頻繁にスキップし、最も後悔するユースケースです。一度も実行されたことのないエラー処理は、存在しないエラー処理に等しいです。モックを徹底的なAPIアサーションと組み合わせて、各失敗パスが想定ではなく検証されるようにしてください。

モックする価値のある2番目の種類のエラーがあります。それは、HTTPとしては有効だが、あなたのドメインにとっては間違っているレスポンスです。例えば、負の価格を持つ200レスポンス、enumにないステータスを持つ注文、nextカーソルがどこにも向いていないページネーションされたリストなどです。正しいサーバーであれば、これらを送ることは決してありません。しかしモックであれば可能です。クライアントに意図的に不正な形式だが構造は正しいデータを供給することで、パースコードが暗黙のうちにしている仮定を発見できます。

サードパーティAPIの代用

テスト内で実際の決済プロセッサ、マッピングサービス、または配送APIを呼び出すのは遅く、場合によっては呼び出しごとに費用がかかり、あなたが制御できないサービスに依存します。もし彼らのサンドボックスがダウンすれば、あなたのテストスイートもダウンします。

サードパーティをモックしましょう。一度実際のレスポンスを記録するか、公開されているスキーマからモックを構築し、それに対してテストを実行します。テストは高速かつ無料になり、決定論的になります。ベンダーが障害を起こした場合でも、テストは機能し続けます。

メンテナンスコストは発生します。サードパーティはあなたに通知することなくAPIを変更する可能性があり、その場合あなたのモックはそれに気づきません。解決策は、実際のサービスを呼び出してレスポンスがまだモックの形状と一致しているかを確認する小さな定期ジョブです。この契約チェックだけが、あなたがライブのサードパーティに触れる唯一の場所であり、ユーザーが気づく前に乖離を捉えます。また、ベンダーの変更ログを購読しておくことも価値があります。そうすれば、契約テストが失敗する前に計画された変更を知ることができます。

デモとプロトタイプの強化

クライアントの前でライブサービスを呼び出すデモはギャンブルです。遅いクエリ、空の結果セット、あるいは不運な障害が、磨き上げられたプレゼンテーションを謝罪に変えてしまう可能性があります。

モックはデモを決定論的なものにします。デモに必要なデータを正確にスクリプト化できます。例えば、時間通りに発送される注文、健全な数値を示すダッシュボード、クリーンな結果を返す検索などです。これはプロトタイプにも当てはまります。バックエンドが存在するずっと前からUIフローを検証したり、機能を提案したりできます。なぜなら、モックがプロトタイプが期待するあらゆるレスポンスを提供するからです。

ここでのポイントはテストではなく、制御です。あなたは視聴者が見るものを決定し、外部の何ものもそれを台無しにすることはできません。初期段階の作業では、モックは人々にクリック可能なものを提供するための最速の方法となることがよくあります。このカテゴリのツール比較については、オンラインAPIモックツールに関するこの記事で解説されています。

プロトタイプのモックは、設計ドキュメントとしても機能します。モックが最終的なAPIが提供する正確な形状を返す場合、それに対して記述するフロントエンドコードは、使い捨ての足場ではなく、実際のコードです。バックエンドが後で同じ契約を尊重すれば、プロトタイプはベースURLの変更だけで製品になります。これが、一時的な補助として使われるモックと、先行開始の手段として使われるモックの違いです。

CIの高速化と安定化

CIで外部サービスを呼び出すテストスイートは、それらのサービスが持つあらゆる問題を継承します。ネットワークの瞬断、レート制限、別のビルドが変更した共有ステージングデータなど、それぞれがレビュー中のコードとは何の関係もない不安定な失敗につながります。

不安定なテストは、人々が失敗を無視するようになり、CIの目的を損ないます。外部依存関係をモックすることで、スイートは独立した環境になります。すべての実行は同じ既知の状態から始まり、ネットワークの往復がないため高速に完了し、コードが実際に壊れている場合にのみ失敗します。

1つの例外を設けてください。コミットごとのスイートとは別に、定期的に実際のAPIに対して薄い層の契約テストを実行します。これにより、モックがまだ本番環境と一致していることを確認します。コミットごとのスイートは高速でモックされたままになり、スケジュールされたジョブが乖離を捕捉します。この分離は、健全なCI/CDテストパイプラインの中心です。

速度の向上は、些細な利便性ではありません。12分かかっていたスイートが90秒に短縮されれば、チームの働き方が変わります。開発者は期待する代わりに、プッシュする前に毎回それを実行します。レビュー担当者は、差分を読む時間で結果を確認できます。高速で独立したスイートは、人々が実際に信頼するものであり、信頼こそが自動テストの投資収益率の全てです。

モックしてはいけない場合

モックには失敗モードがあります。それは、現実と一致しなくなったモックです。テストはグリーンなままなのに本番環境が壊れるのは、テストが架空のものを検証しているためです。

テスト対象が統合そのものである場合は、モックを使用しないでください。契約テストやエンドツーエンドチェックは、実際の境界を検証するために存在するため、それらをモックすると存在意義がなくなります。実際のサービスに対して一度も検証しない依存関係をモックしないでください。未検証のモックは乖離していきます。また、テスト環境で実際のサービスが高速、無料、かつ信頼できる場合は、モックに手を出すべきではありません。モックは単なるオーバーヘッドになります。

一般的な経験則としては、速度、分離、および制御のためにモックを使用し、モックが依然として真実であることを確認するために、現実に触れる小規模で正直なテストセットを保持することです。モックと契約チェックを1箇所にまとめたい場合は、ApidogがAPI設計からモックを生成し、モックとライブエンドポイントの両方に対してテストを実行します。これを設定するには、Apidogをダウンロードし、既存の仕様から始めましょう。概念的な基礎については、モックAPIが実際に何であるかをご覧ください。

よくある質問

実際のAPIを呼び出す代わりにAPIをモックすべきなのはいつですか？

速度、分離、または制御が必要な場合にモックを使用します。例えば、未完成のバックエンドに対する並行開発、実際のサーバーが生成しないエラーパスのテスト、遅いまたは有料のサードパーティサービスの代用、デモの実行、CIの安定化などです。契約テストやエンドツーエンドテストには、実際のAPIを呼び出します。

モックは統合テストに取って代わりますか？

いいえ。モックは、自身のコードをチェックする単体テストやコンポーネントテストのためのものです。統合テストと契約テストは、実際のサービスが契約と一致することを確認する役割があるため、実際の境界にアクセスする必要があります。これらをモックすると、その目的が失われます。

モックが古くならないようにするにはどうすればよいですか？

理想的にはOpenAPIのような共有スキーマからモックを生成し、契約変更によって自動的に更新されるようにします。その後、実際のAPIに対して定期的に契約テストを実行し、ライブレスポンスがまだそのスキーマと一致していることを確認します。これにより、ユーザーに影響が出る前に乖離が捕捉されます。

制御できないサードパーティAPIをモックできますか？

はい、それは最も強力なユースケースの1つです。サードパーティの実際のレスポンスを記録するか、公開されているスキーマからモックを構築し、速度と信頼性のためにモックに対してテストを実行します。ベンダーがAPIを変更したときに気づくように、ライブサービスに対する定期的なチェックを追加してください。

モックはデモやプロトタイプに役立ちますか？

非常に役立ちます。モックは、ライブの障害や不運なデータによるリスクなしに、視聴者に見せたいデータを正確にスクリプト化することで、デモを決定論的にします。プロトタイプの場合、モックを使用すると、バックエンドが存在する前にUIフローを構築および検証できます。