typescript-testing

# TypeScript テストルール ## 前提条件の検出 フレームワークやコマンドを選択する前に、`package.json`、ロックファイル、テスト設定、既存テストのimportを確認する。Vitest固有のルールはVitestが設定されている場合にのみ適用する。それ以外は、以下の振る舞い、独立性、証跡に関するルールを維持しつつ、リポジトリで設定済みのTypeScriptテストハーネスを使用する。実行可能なハーネスを特定できない場合は、確認したパスと不足しているコマンドまたは設定を報告する。 ## テストフレームワーク - **Vitest**: リポジトリ設定または既存テストで選択されている場合に使用 - テストのインポート: `import { describe, it, expect, beforeEach, vi } from 'vitest'` - モックの作成: `vi.mock()` を使用 ## テストの基本方針 ### 品質要件 - **カバレッジ**: カバレッジは目標ではなく未テスト領域を見つける診断シグナルとして扱う（目標化すると自明なテストに歪む — グッドハートの法則）。クリティカルパス・ビジネスロジック・リグレッションが問題になる振る舞いにテストを集中させる。パーセンテージ達成のためではなく、ギャップが実際のリグレッションを無防備にしている箇所でカバレッジを上げる。数値しきい値はプロジェクトの CI 設定に委ねる - **独立性**: 各テストは他のテストに依存せず実行可能 - **再現性**: 時刻、乱数、環境値、外部I/Oを制御し、同一の入力から同一の観測可能な結果を得る - **可読性**: 各テストは1つの振る舞いを名前で示し、setup・action・assertionを分け、その振る舞いで使用する値だけをfixtureに含める ### テストの種類と範囲 1. **単体テスト（Unit Tests）** - 個々の関数やクラスの動作を検証 - 外部依存はすべてモック化 - 最も数が多く、細かい粒度で実施 2. **統合テスト（Integration Tests）** - 複数のコンポーネントの連携を検証 - テスト対象の振る舞いを構成するin-processコンポーネントは実物を使用。外部I/Oはモック範囲の判断を参照 - 主要な受け入れ基準を実装するフロー、またはin-processコンポーネントの境界をまたぐフローを検証 3. **E2Eテストでの機能横断検証** - 新機能追加時、既存機能への影響を必ず検証 - 各統合ポイントを分類する: 失敗が主要なユーザージャーニーまたは公開契約を壊すなら「高」、副次的な観測可能な振る舞いを劣化させるなら「中」。「高」と「中」をカバーする - 検証パターン: 既存機能動作 → 新機能有効化 → 既存機能の継続性確認 - 判定基準: 元の受け入れ基準で指定されたレスポンスフィールドと観測可能な振る舞いを維持する。処理時間のしきい値は、要件またはプロジェクト設定で値と計測方法が定義されている場合にのみ適用する - CI/CDでの自動実行を前提とした設計 ## テストの実装規約 ### ディレクトリ構造と命名規則 - テストは対象モジュールと同じ階層の `__tests__/` に置く - テストファイル: `{対象ファイル名}.test.ts` - 統合テストファイル: `...