業務で MSW を使ってみた感想
前提
- MSW v1.3.0
- REST API
経緯
業務で管理画面を開発した。自分はフロントエンドの開発メンバーとして参加した。
始めに Open API で API の I/F をバックエンドチームと共に定義し、その後はフロントエンドとバックエンドでチームを分けて並行して開発を進めた。
並行して開発を進めるので、フロントエンドチームが自由に API のモックを実装できた方が効率良く開発できそうだった。1
また、フロントエンドの自動テストも整備していきたいと思っていた。
採用理由
API のモックを実装するために、MSW を採用することにした。採用理由としては、モックの再利用が可能なことと、他社事例が複数あったことが挙げられる。
再利用可能
MSW はブラウザ(Service Worker) と Node.js 環境の両方で動作する。 なので、1 度 API のモックを実装すると、自動テスト(Unit テストや E2E テスト)から再利用できる。
React Testing Library の
Example では MSW によるテストの実装例が紹介されている。このドキュメントでは window.fetch
をモックするよりも MSW を使うことを推奨している。
自動テストを実装する際にも API のモックは必要なので、開発時とテスト実装時でモックを再利用可能なのは嬉しい。
他社事例
複数の企業から MSW を採用した開発事例が公表されている。
- Mock Service WorkerでAPIをモックして開発をスムーズに進められた話
- OpenAPIとMSWを使ってユーザーのフォロー機能を実装した話
- OpenAPI × Orval × MSW × Next.jsでのスキーマ駆動開発実践
概ね MSW に対して肯定的な内容であることと、業務での利用にも耐えられるライブラリであることが分かった。
使ってみてどうだったか
ここからは、実際に自分が MSW を利用した開発をしてみて、出来たこと・出来なかったことを書く。
出来たこと
- フロントエンドチーム内で簡単に API のモックを実装できた
- JavaScript で実装可能なので、バックエンドが別言語で実装されている場合は特に嬉しい
- エラーレスポンスの再現が簡単にできるので、異常系の実装が楽だった
- Jest と React Testing Library を使った単体テストで、API のモックを再利用できた
server.use
で一時的にレスポンスを変更できるので、異常系のテストケース実装が楽だった
出来なかったこと
- 現時点では Next.js の App Router で動作しなかった(Support Next.js 13 (App directory) #1644)
Location
ヘッダーを付与したレスポンスに対して Chrome がリダイレクト処理を行わない- Service Worker の制約?
Content-Type
ヘッダーの値がtext/csv
のレスポンスに対して、Chrome が CSV ダウンロードに失敗する- 現時点では
multipart/form-data
形式の Request Body を取得できない(Support "req.formData()" #1327)- Jest で画面から正しいリクエストが送信されているかをテストできない
上記の Chrome が意図した動作をしない API については、Next.js の API Route の場合は正しく動作したのでこちらで代用した。
MSW 固有の問題ではないが、フロントエンドの開発完了後に実際の API と結合テストを行った際に認証系のバグがいくつか発生した。これは認証が必要な API も常に正常レスポンスを返すようにモックを実装していたからだった。認証が必要な API はモック実装でも Cookie やヘッダーの値を参照して認証エラーを返すような分岐を実装した方が事前にバグを発見できたはずなので、1 つ学びになった。
まとめ
結論として、今回の管理画面開発では MSW を利用して良かったと思う。
事前に OpenAPI を利用して API の I/F を決めておき、MSW で API のモックを実装することで、フロントエンド実装の依存先がなくなり、全てフロントエンドチーム内で作業を完結できるようになった。バックエンドチームとのコミュニケーションも有意義なものが多くなり、効率が良かったと感じる。
MSW を利用して開発を終えた後に実際の API との結合テストした際には、認証系のバグは出てしまったが、レイヤー間での認識齟齬によるバグはほとんどなかった。
また、Jest と React Testing Library を利用したコンポーネントのテスト実装では、開発に使用した API のモック実装を再利用できたため工数の短縮にも繋がった。
API の I/F が事前に定義されている場合は、今後のフロントエンド開発の業務でも使っていきたいと思う。
Footnotes
-
便宜上モックという用語を使うが、スタブやフェイクの方が適切な用語かもしれない。 Gerard Meszaros (2007). x Unit Test Patterns: Refactoring Test. Addison-Wesley Professional ↩