モックAPIとは？わかりやすく解説

モックAPIは、実際のAPIと同じように動作する偽のAPIです。同じリクエストを受け入れ、同じ形式でレスポンスを返し、呼び出し可能なURL上に存在しますが、そのURLの背後には実際のデータベース、ビジネスロジック、実際のサービスはありません。レスポンスは事前に定義されたものです。

それは取るに足らないことのように聞こえますが、そのアイデアは単純です。その価値は、それが可能にするものにあります。つまり、その背後にあるものが存在しない間に、または実際のものが遅すぎたり、費用がかかりすぎたり、信頼性が低すぎて呼び出せない間に、インターフェースに対して構築し、テストできることです。この解説では、この用語を正確に定義し、モックが混同されがちなものと区別し、モックの動作を決定する静的と動的の区別を説明します。

モックAPIとは実際に何なのか

突き詰めると、モックAPIはリクエストとレスポンスのマッピングです。リクエストが来ると、モックは設定されたルールと照合し、レスポンスを選択して返します。特に指示しない限り、その間に計算処理は行われません。

モックには3つの部分があります。1つはインターフェースです。これは、実際のAPIと完全に一致すべき、受け入れるルート、メソッド、およびパラメーターです。2つ目はレスポンス定義です。これは、返すボディ、ステータスコード、およびヘッダーです。3つ目はマッチングロジックです。これは、単純なパスの一致から、クエリパラメーターやヘッダーによって分岐するルールまで、特定の要求に対してどのレスポンスを返すかをモックが決定する方法です。

インターフェースが実際のAPIと一致するため、モックを呼び出すコードはそれが偽物であることを知りません。ベースURLを交換するだけで、同じクライアントが実際のサービスと通信します。この交換可能性が要点です。実際にモックを構築する方法については、テストのためのAPIモック作成ガイドをご覧ください。

モックAPIが何でないかを正確に理解することが役立ちます。それはキャッシュではありません。キャッシュは実際のレスポンスを保存するのに対し、モックはそれらを「作り出す」からです。それはサンドボックスではありません。ベンダーサンドボックスは実際の簡略化されたロジックを実行するのに対し、モックは全くロジックを実行しないからです。そして、それはステージング環境でもありません。ステージングは実際のシステムの完全なデプロイメントだからです。モックはこれら3つ全てよりも軽量です。それは、事前に定義された応答が背後にあるAPIの入り口に過ぎず、それ以上のものではありません。

モックとスタブ

人々は「モック」と「スタブ」を同じ意味で使いますが、テストにおいては異なる意味を持ちます。

スタブはより単純な概念です。それは呼び出しに対して「決められた答え」を返すだけで、それ以上のものではありません。ユーザーを要求すると、固定のユーザーを返します。スタブはどのように呼び出されたかについて何も意見を持ちません。

厳密なテストの意味でのモックは、インタラクションも検証します。それは、呼び出されたかどうか、何回呼び出されたか、どのような引数で呼び出されたかをアサートできます。モックは、単に値を供給するだけでなく、呼び出しが間違っていたためにテストを失敗させることができます。

日常的なAPI作業ではその境界線は曖昧で、「モックAPI」という言葉は通常、両方をカバーします。役立つポイントは、スタブは応答し、モックは応答しつつ監視するということです。コードが受け取るデータのみがテストの関心事である場合、スタブ形式のレスポンスで十分です。コードが適切に、適切な方法で呼び出しを行ったかどうかが関心事である場合、真のモックが追加する検証が必要になります。より広い語彙については、バリデーションと検証の違いを参照してください。

他にも関連する2つの用語があります。「フェイク」は、実際のデータベースの代わりに使用されるインメモリデータベースのように、動作するが簡略化された実装です。それにはロジックがありますが、その量は少ないです。「スパイ」は、実際のオブジェクトをラップし、その動作を変更せずにどのように呼び出されたかを記録します。API開発で使われる「モックAPI」という用語は、オプションの検証機能を持つスタブに最も近く、実際のURLでHTTP経由で提供されます。用語を厳密に使い分ける必要はありませんが、これらの違いを知っていると、テスト関連のドキュメントを読み進める際に迷わずに済みます。

モックAPIと実際のサーバー

実際のサーバーとモックサーバーは同じURLに存在し、同じJSONを返すことができます。したがって、違いはエンドポイントの背後で何が起こるかにあります。

実際のサーバーは真実を教えてくれます。それは実際のコードを実行し、システムが機能することを証明します。また、遅く、ステートフルであり、実際の副作用（カードへの課金やメール送信など）を引き起こす可能性があるため、それに対するテストでは注意が必要です。

モックサーバーは、あなたが伝えたことだけを返します。それは高速で、副作用がなく、完全に予測可能であるため、開発やほとんどのテストに理想的です。しかし、モックは実際のロジックを実行しないため、誤っていてもそれに気づくことはありません。そのため、一部のテストは実際のサーバーで行う必要があります。このトレードオフについては、モックサーバーと実際のサーバーの比較で詳しく説明されています。

静的モックと動的モック

モックは2つの方法のいずれかでレスポンスを返し、その選択によってモックの使い心地が変わります。

静的モックは固定のペイロードを返します。あなたは正確なJSONを一度書き、一致するすべてのリクエストが同じボディを返します。静的モックは予測可能であるため、アサートしやすいという特徴があります。その弱点は現実性です。単一のハードコードされたペイロードでは、長い文字列、空の配列、または予期せぬヌルで壊れるコードのバグを表面化させることはできません。

動的モックは、リクエストごとにレスポンスを生成します。固定の"id": "user_1001"の代わりに、呼び出しごとに新しいUUIDを生成します。一つの名前ではなく、毎回異なるリアルな名前を返します。動的モックは通常、Faker.jsのようなデータ生成文法を使用してこれを実現します。これにより、emailという名前のフィールドはメールアドレスを生成し、created_atは日付を生成します。これらはより現実的で、エッジケースを明らかにするのに優れていますが、正確にアサートするのが難しいというコストが伴います。

ほとんどのチームは両方を使用します。既知の単一値が必要なアサート中心のユニットテストには静的モックを使用します。固定の応答よりも多様性が重要な開発、デモ、ファズスタイルのカバレッジには動的モックを使用します。

動的モックは条件付きにすることもでき、これは単純な生成を超えた一歩です。条件付きモックはリクエストに基づいて分岐します。たとえば、/orders/404へのリクエストには404を返し、不正なトークンを含むリクエストには401を返し、その他の場合は通常の200を返します。これにより、1つのモックエンドポイントで正常パスと複数の失敗パスを同時にカバーできます。健全な実際のサーバーではオンデマンドで生成されないエラーレスポンスを再現できるため、これがモックをテストに真に役立たせる理由です。

開発におけるモックAPIの役割

モックAPIは3つの点で役立ちます。開発の初期段階では、フロントエンドとバックエンドのチームが契約に合意し、並行して開発を進めることができるため、互いに待つ必要がありません。テスト中は、コードをネットワークの不安定さから隔離し、実際のサーバーではオンデマンドで生成されないエラー応答をトリガーできます。また、デモやプロトタイプ作成においては、プレゼンテーション中にライブ依存関係が失敗することなく、制御された予測可能なデータを提供します。これらのシナリオについては、APIモックのユースケースガイドでさらに詳しく説明されています。

繰り返されるリスクは「ズレ（drift）」です。モックはインターフェースのスナップショットであり、インターフェースは変化します。実際のAPIがフィールドを追加したり名前を変更したりすると、独立したモックは古い形式を提供し続け、あなたのテストはもはや存在しない契約に対してパスしてしまいます。

解決策は、モックを手書きするのではなく、派生したものとして扱うことです。実際のAPIが公開するのと同じスキーマからモックを生成すれば、契約が変更されるとモックも再生成されます。手作業で作成したモックはすぐに古くなるコピーですが、仕様から生成されたモックは常に最新のスナップショットです。この違いは初日には現れませんが、半年後にモックがまだ信頼できるかどうかを決定します。Apidogはこのように機能します。APIを一度設計すると、フィールド名から推測された現実的なデータと共に、その設計からモックエンドポイントが生成されます。モック、ドキュメント、そしてAPI契約テストはすべて単一のソースから読み取られるため、同期が保たれます。デザインからモックまでのフローをエンドツーエンドで見るには、Apidogをダウンロードしてください。

よくある質問

モックAPIとは簡単に言うと何ですか？

モックAPIは、実際のAPIを模倣した偽のAPIです。同じルートを公開し、同じ形式でレスポンスを返しますが、その背後には実際のロジックやデータベースはありません。レスポンスは事前に定義されており、これにより実際のサービスが存在する前にインターフェースに対して構築し、テストすることができます。

モックとスタブの違いは何ですか？

スタブは決められたレスポンスを返すだけで、それ以上のものではありません。厳密なテストの意味でのモックは、インタラクションも検証します。そのため、適切な引数で適切な回数呼び出されたかをチェックできます。スタブは応答し、モックは応答しつつ監視します。

モックAPIは実際のサーバーとどう違うのですか？

モックは事前の計算なしで事前に定義されたレスポンスを返すため、高速で予測可能であり、副作用がありません。実際のサーバーは実際のロジックを実際のデータベースに対して実行するため、遅くステートフルですが、システムが実際に機能することを証明します。開発にはモックを使用し、契約テストやエンドツーエンドテストには実際のサーバーを使用します。

静的モックと動的モックのどちらを使うべきですか？

アサート対象となる予測可能な単一の値が必要な場合は静的モックを使用します。これはユニットテストに適しています。エッジケースを捉える現実的で多様なデータが必要な場合は動的モックを使用します。これは開発やデモに適しています。多くのチームが両方を使用しています。

モックAPIが不正確になるのを防ぐにはどうすればよいですか？

モックを手書きするのではなく、実際のAPIが公開するのと同じスキーマから生成します。契約が変更されたときに、モックも再生成されます。実際のAPIに対する定期的な契約テストでこれを補強することで、残存するズレを早期に発見できます。