フロントエンドの自動テストにおけるAPI コールのモック化の方針を定めたい

[KentaHizume]

概要

フロントエンドの自動テストにおいて、
ユースケースを模倣するインタラクションテストを実行するにあたって、
API コール部分をどのようにモックすべきかについて検討したいです。

• アプリケーションアーキテクチャCSR編にテスト方式について追記する maia#92

msw/Vitestの比較

それぞれメリット・デメリットが裏返しになっている状態です。

	メリット	デメリット
msw	API クライアント部分（axios含む）をテストできる	テストケースの実装箇所とモックのハンドラーの実装箇所がどうしても離れてしまう、ケースに応じたハンドラーを作ると実装がややこしくなる
Vitest	テストケースとモックしたレスポンスを近くに配置できる、ケースに応じたレスポンスを実装しやすい	API クライアント部分（axios含む）はテストできない

案

1. Vitestのみ使用

• APIクライアントのテストについては手動テストで確認するという方針です。

2. mswのみ使用

• mswのモックのメンテナンスのリスクを受け入れるという方針です。

3. axiosのみmswを用いてテストする

• 1 と 2 の折衷案です。

論点

3 が最も網羅的になるため望ましいようには見えるのですが、
maia/maris の標準構成に従っている場合、
APIクライアントはopenapi-generatorで自動生成するため、
事実上テスト対象はapi-client/index.tsのみとなります。
この1ファイルのためだけにmswのNode.js用のモック一式を作る価値があるのかどうかが論点と思っています。

案

大方針としては、インタラクションテストのAPIコールではVitestのみを使用し、APIクライアントのテストについては手動テストで確認で十分と考えています。

理由

• HTTP レスポンスコードとカスタムエラーの詰め替えといった定型的な処理が中心で、不具合が起きそうなロジックが実装される可能性が低そうに見えるためです。

懸念点

• 認証周りの処理が入ってきた場合に、APIクライアントの設定ファイルに不具合が起きやすいロジックが実装される可能性がありうると思っています。下記はAzureADB2Cサンプルの例です。

async function addTokenAsync(config: apiClient.Configuration): Promise<void> {
  // 認証済みの場合、アクセストークンを取得して Configuration に設定します。
  if (await authenticationService.isAuthenticated()) {
    const token = await authenticationService.getTokenAzureADB2C();
    // eslint-disable-next-line no-param-reassign
    config.accessToken = token;
  }
}

[KentaHizume]

VitestのAPI クライアント部分（axios含む）はテストできないというデメリットについて、
もし何らかテストしたほうがよい処理が出てきた場合は、その箇所だけ単体テストを実装すれば軽減できる。
（APIクライアントの設定はインタラクションテストで確認する観点ではない）

Vitestを使用する追加のメリットとして、いくつか典型的なパターンを学習させれば、Copilot等の生成AIでモック用のテストデータを含めて自動生成できるという展望がある。