The latest updates on your projects. Learn more about Vercel for Git ↗︎

RepositoryをInterfaceを使用して抽象化しているため、APIをモックするというよりはRepositoryをモックした方が良いと思います。つまり、InMemoryで動くRepositoryをテスト用のRepositoryとして使用するのが良いかと。

また、それに伴って、本番環境などではapiを使用したRepositoryをテスト環境ではInMemoryで動作するRepositoryを自動で割り当ててくれるようなDIツールの導入も行った方が良いかもしれません。

以上を踏まえて、実施すべきテストは主に以下の2点になるかと思います。

• RepositoryのInterfaceに対するUnit Test（jest）
• frontend全体に対する結合テスト or E2Eテスト（playwright or vitest）
  • Repositoryを切り替えることでテスト時のバックエンドとの連携の有無を設定できると思います。

vitestというvue.js公式がおすすめしているツールがあったので共有しておきます。
また、下記のリンクはvue.jsでのテストに関する記事です。

• https://ja.vuejs.org/guide/scaling-up/testing.html#component-testing

RepositoryをInterfaceを使用して抽象化しているため、APIをモックするというよりはRepositoryをモックした方が良いと思います。つまり、InMemoryで動くRepositoryをテスト用のRepositoryとして使用するのが良いかと。

今回追加したいのはフロントエンドの範囲内においてユーザの行動フローの完遂を保証する結合テストという認識です。
そのため「フロントエンドの範囲内でなるべく結合してテストする」ことが重要だと考えています。
しかし、Repository をモックすると Production （ = Develop ではない）Repository のテストや、axios や aspida などのテストができなくなり、前述の目的が達成できないと考えています。

以上を踏まえて、実施すべきテストは主に以下の2点になるかと思います。
RepositoryのInterfaceに対するUnit Test（jest）
frontend全体に対する結合テスト or E2Eテスト（playwright or vitest）
Repositoryを切り替えることでテスト時のバックエンドとの連携の有無を設定できると思います。

そして、これらの 2 つのテストを分割するのではなく、Reposoitory も含めて結合してテストしたいと考えています。

この観点についてはいかがでしょうか？

ありがとうございます！
いいですね、単体テスト等で使えないか見てみます！

vitestというvue.js公式がおすすめしているツールがあったので共有しておきます。
また、下記のリンクはvue.jsでのテストに関する記事です。

https://ja.vuejs.org/guide/scaling-up/testing.html#component-testing

@HosokawaR

しかし、Repository をモックすると Production （ = Develop ではない）Repository のテストや、axios や aspida などのテストができなくなり、前述の目的が達成できないと考えています。

説明が下手でした。すみません。
Repositoryをモックするのではなく、InMemoryで動作するRepositoryを使用してfrontend全体に対するテストを行うという認識です。

axiosなどを使用したRepositoryに対する動作確認はRepositoryに対する単体テストで対応しようと思っています。

ですので、playwrightを使用してモックを作成する必要は基本的にはないかと思います。