Vitest + Playwright

コンテキスト

小規模チームで限られたリソースの中、テストの投資対効果を最大化する必要がある。すべてのレイヤーにテストを書くのではなく、最もバグを防げるレイヤーに集中したい。

検討した選択肢

• 2層構成: 統合テスト (Vitest) + E2E (Playwright) — バックエンドはtRPCルーター単位の統合テスト、フロントエンドはユーザーフロー単位のE2Eテスト
• 3層構成: ユニットテスト + 統合テスト + E2E — 従来型のテストピラミッド
• コンポーネントテスト中心 (Testing Library) — フロントエンドをコンポーネント単位でテスト

決定

Vitest による統合テスト + Playwright によるE2Eテストの2層構成を採用する。コンポーネント単体テスト（Testing Library）は採用しない。

Vitest + Playwrightを選んだ理由

• 統合テストの費用対効果が最も高い — tRPCルーター経由のテストにより、UseCase → Domain → Infrastructure の全レイヤーを一度に検証できる。モックによるレイヤー間の乖離リスクがない
• 実DBに対してテストする — データベースのモックは行わず、テスト用のPostgreSQLに対して実行する。マイグレーションやクエリの実動作を検証できる
• コンポーネントテストを省略する理由 — UIコンポーネントのロジックはデザインシステム（@bi-shop-it/ui）側で担保される。アプリケーション側のコンポーネントはデータの表示が中心であり、E2Eテストでユーザーフロー全体を検証する方が効率的である
• TDDサイクルとの統合 — バックエンドはTDD（Red → Green → Refactor）で開発し、フロントエンド実装後にE2Eテストを追加する

影響

• 開発サイクル — テスト作成 → バックエンド実装 → リファクタ → フロントエンド実装 → E2Eテスト の順で進める
• テスト用のDB環境が必要 — ローカル開発ではDockerでPostgreSQLを起動し、テストごとにデータをリセットする
• devログインエンドポイント — E2Eテストおよび開発時のOAuth認証バイパス用に /api/dev/login を提供する（開発環境のみ）