Mock Service Worker (MSW) の代替：フルAPIモックプラットフォームを代わりに使うべき時

フロントエンドのテストを書いている方なら、おそらくMock Service Worker (MSW)に出会ったことがあるでしょう。これはブラウザやNode内でリクエストをインターセプトするための定番ライブラリであり、ユニットテストやコンポーネントテストにおいては非常に強力です。このガイドでは、MSWが得意とすること、スケーリングが難しくなる点、そしてホスト型APIモックプラットフォームの方が適している場合について説明します。ボタン## Mock Service Workerとは？ Mock Service Workerは、ネットワークリクエストをソースでインターセプトするJavaScriptライブラリです。ブラウザでは、送信される`fetch`や`XMLHttpRequest`呼び出しを捕捉するService Workerを登録します。Nodeでは、リクエストレイヤーにパッチを適用することで、JestやVitestでも同じハンドラーが実行されます。メソッドとパスに一致するリクエストハンドラーを記述し、好きなレスポンスを返します。 The design is clever. Your application code keeps calling the real network APIs. MSW sits in the middle and answers, so you don’t stub `fetch` or swap your HTTP client. The same mock definitions work in tests and in a running dev build, which is why so many React and Vue teams reach for it. You can dig into the [MSW source on GitHub](https://github.com/mswjs/msw) to see how the interception layer works. この設計は巧妙です。アプリケーションコードは実際のリモートAPIを呼び出し続けますが、MSWがその途中で応答するため、`fetch`をスタブしたりHTTPクライアントを切り替えたりする必要がありません。同じモック定義がテストと実行中の開発ビルドで機能するため、多くのReactおよびVueチームがこれを利用しています。インターセプション層の仕組みについては、[GitHubのMSWソース](https://github.com/mswjs/msw)を深く掘り下げてみることができます。 典型的なハンドラーは次のようになります。 ```js import { http, HttpResponse } from 'msw' export const handlers = [ http.get('/api/users/:id', ({ params }) => { return HttpResponse.json({ id: params.id, name: 'Ada Lovelace' }) }), ] ``` これがその最大の魅力です。モックはコードの隣に配置され、テストとともにバージョン管理され、JavaScriptが実行される場所ならどこでも実行できます。 ## MSWが輝く場所 MSWは、モックとそのコンシューマーが同じコードベースにある場合に非常に適しています。MSWが本当に適切なツールであるいくつかのケースを挙げます。 - **コンポーネントテストおよびユニットテスト。** コンポーネントをレンダリングし、実際のリクエストを発行させ、事前に用意されたデータを返します。テストダブルを設定する必要はありません。クライアントを直接スパイするのと比較するなら、[API呼び出しのJestモック](https://apidog.com/jp/blog/jest-mock-api-call)とはどう異なるかをご覧ください。 - **ローカルでのフロントエンド開発。** バックエンドが存在する前にUIを構築します。要求に応じて、ローディング、エラー、または空の状態をシミュレートするためにハンドラーを切り替えます。 - **決定論的なCI。** テストはライブサーバーに触れないため、ネットワークの状態や共有ステージングデータによる不安定化がありません。 - **1つの言語、1つのチーム。** モックを作成する人とそれを使用する人が同じ場合、リポジトリにハンドラーを保持するのが最も簡単な方法です。 もしこれがあなたの状況を説明しているなら、おそらく他に何も必要ないでしょう。MSWは無料でオープンソースであり、まさにこの目的のために作られています。 ## MSWが限界に達し始める場所 MSWが単一のリポジトリで優れている点、つまりリポジトリ内のコードとして存在するモックが、多くの人が関与し始めると限界になることがあります。チームがそれを使いこなせなくなる傾向があるのは次のとおりです。 ### 非JavaScriptコンシューマー MSWのハンドラーはJavaScriptです。モバイルチームがSwiftやKotlinを使用している場合、またはバックエンドの統合テストがGoやPythonで実行されている場合、それらのチームはあなたのハンドラーをインポートできません。彼らは独自のモックを必要とし、それはあなたのモックと乖離してしまいます。リアルなURLを介してHTTPで通信する言語に依存しない[モックサーバー](https://apidog.com/jp/blog/mock-server-for-api-testing)は、言語に関係なくすべてのクライアントで機能します。 ### 共有され、常にオンになっているモック MSWはプロセス内で実行されます。QAエンジニア、デザイナー、またはパートナーチームが各自のマシンからアクセスできる共有URLはありません。複数の人が同時に使用する1つのエンドポイントが必要になった瞬間、単一のブラウザタブにバインドされたService Workerではなく、安定したアドレスを持つホスト型モックサーバーが必要になります。 ### デザイン優先およびスキーマ駆動型ワークフロー コードを記述する前にOpenAPIでAPIを設計する場合、仕様から自動的に生成されるモックが必要です。そうすれば、モックが契約と矛盾することはありません。MSWはハンドラーを手動で記述することを想定しています。スキーマから直接モックを生成することは、異なるモデルです。このアプローチについては、[APIモック](https://apidog.com/jp/blog/api-mocking)とその周辺パターンに関するこのガイドで詳しく読むことができます。 ### スケールでのリアルで動的なデータ MSWは、ハンドラーがコード化するものを返します。多くのフィールドにわたってリアルなデータを得るには、そのロジックを自分で記述する必要があります。fakerスタイルの生成とフィールド名の推論を組み込んだプラットフォームは、一つ一つ手作業で作成することなく、リアルなレスポンスを提供します。 ## MSWと完全なAPIモックプラットフォームの比較 正直な比較です。どちらの項目も抽象的に「優れている」わけではありません。それぞれ異なる問題を解決します。

結論として：MSWはフロントエンドテストやローカル開発に適しています。[Apidog](https://apidog.com)のようなプラットフォームは、モックが共有される必要があり、言語に依存せず、または仕様によって駆動される場合に適しています。 ## 置き換えではなく、補完としてのApidog はっきりさせておくと、[Apidog](https://apidog.com/api-mocking/)はJestやVitest内のMSWのドロップインではありません。テストファイルにインポートするJavaScriptライブラリではありません。ユニットテストの上位層として扱い、モックがチーム全体の共有され、言語に依存しないリソースとなる場所と考えるべきです。 実際にどのように見えるかを見てみましょう。ApidogでAPIを設計またはインポートすると、スキーマからモックエンドポイントが自動的に生成されます。そのモックには、フロントエンド、モバイル、QAのチームメンバー全員が呼び出せる実際のURLが与えられます。Apidogはフィールド名から推測して、リアルなデータでレスポンスを埋めます。例えば、`email`というフィールドにはメールアドレスが、`createdAt`には日付が返されます。特定の500エラーレスポンスや特定のエッジケースが必要な場合は、カスタムルールを記述することもできます。 モックが設計とテストと同じスキーマから派生しているため、契約と同期を保ちます。これは手書きのハンドラーでは保証できない部分です。スキーマからモックへの生成がツール間でどのように比較されるかを知りたい場合は、[最高のAPIモックツール](https://apidog.com/jp/blog/best-api-mock-tools)をまとめたこのガイドで各オプションを比較しています。 多くのチームがたどり着く実用的な分割は次のとおりです。 - フロントエンドリポジトリ内のコンポーネントテストおよびユニットテストにはMSWを使用し続ける。 - クロスチームの統合、デモ、および非JSコンシューマーにはホスト型モックを使用する。 どちらか一方を選ぶわけではありません。それぞれが適した場所で使用するのです。既存のMSW設定と並行してホスト型を試したい場合は、[Apidogをダウンロード](https://apidog.com/download)してください。 ## 知っておくべき他のMSW代替手段 MSWは唯一のモックライブラリではありませんし、プラットフォームが唯一の選択肢でもありません。あなたのスタックに応じて： - **Mockoon**は、コードではなくGUIを使用して、ローカルモックサーバーを素早く立ち上げるためのデスクトップアプリです。 - **WireMock**はJavaベースのモックサーバーで、JVMチームや契約テストに強力です。 - **Prism** by Stoplightは、コマンドラインを介してOpenAPIファイルから直接モックを生成します。 - **json-server**は、JSONファイルをプロトタイピング用の高速REST APIに変換します。 それぞれにトレードオフがあります。WireMockとPrismはバックエンドと契約作業に傾倒しており、Mockoonとjson-serverは高速なローカルセットアップに傾倒しています。もしあなたの障害が具体的に「MSWでは非JSチームメイトを助けられない」ということであれば、あらゆるHTTPベースのモックサーバーがそれを解決します。より広範なフロントエンドの観点から、チームが[ReactでAxiosを使ってAPIをモックする方法](https://apidog.com/jp/blog/react-mock-api-axios)をどのように扱っているかをご覧ください。 ## よくある質問 ### MSWは無料ですか？ はい。Mock Service WorkerはMITライセンスのもとオープンソースであり、商用かどうかにかかわらずどのプロジェクトでも無料で使用できます。共有モックのためにホスト型プラットフォームに移行するときに初めて支払いが発生しますが、Apidogのようなツールにも無料枠が含まれています。 ### Apidogは私のユニットテストでMSWの代わりになりますか？ いいえ、そうしようとするべきではありません。MSWはJavaScriptのテストランナー内でリクエストをインターセプトします。Apidogはホスト型プラットフォームであり、インポート可能なライブラリではないため、MSWのようにJestやVitest内に配置することはできません。代わりに、共有された、クロスチームの、またはスキーマ駆動のモックにApidogを使用してください。テストランナー側のみに焦点を当てる場合、[API呼び出しをモックする方法](https://apidog.com/jp/blog/how-to-mock-api-calls)に関するこのチュートリアルで、コード内のアプローチについて説明しています。 ### MSWはNodeでも動作しますか、それともブラウザのみですか？ 両方で動作します。ブラウザではMSWはService Workerを使用します。Nodeでは、リクエストレイヤーにパッチを適用することで、Jest、Vitest、または任意のNodeテスト環境で同じハンドラーが実行されます。このデュアルモードは、フルスタックJSチームにとって最大の強みの1つです。 ### MSWからホスト型モックサーバーに切り替えるのはいつですか？ モックが共有される必要があるときに切り替える、というより追加すべきです。最も明確な兆候は、非JavaScriptクライアントが必要としている場合、複数の人が同じ安定したURLを必要としている場合、またはAPIをスペック優先で設計し、OpenAPIからモックを自動生成したい場合です。 ## 結論 MSWは、JavaScript内でフロントエンドとユニットテストのリクエストをインターセプトするという、その目的のために非常に優れています。共有された、ホストされた、言語に依存しないモックになろうとはせず、それはそれで問題ありません。モックがリポジトリを離れる必要があるとき、他の言語や他のチームがそれらを必要とするとき、またはスペックから生成したいとき、それがMSWと並行して完全なプラットフォームを追加する瞬間です。 Apidogは、共有された、スキーマ駆動型の一面を処理します。実際のURLを持つホスト型モックサーバー、OpenAPI設計からの自動モック、そしてそのまま使えるリアルなデータを提供します。MSWが得意な場所ではそれを使い続け、テストランナーの境界を越えるすべては[Apidog](https://apidog.com)に任せましょう。Apidogをダウンロードし、フロントエンドを共有モックに向けて違いを体験してください。ボタン