Testing

テスト戦略: 単体・結合・E2E

目的

品質を「後から検証するもの」ではなく「作りながら組み込むもの」として扱う。 テストピラミッドに基づく適切な配分で、保守コストを抑えながら十分な信頼性を確保する。

使うタイミング

• 機能実装開始前にテスト戦略を決めるとき
• バグ修正時に再現テストを書くとき
• [[requirements-definition]] の受け入れ基準をテストケースに落とし込むとき
• カバレッジが低い箇所を補強するとき
• CI/CDパイプラインにテストを組み込むとき

テストピラミッド

        /E2E\        ← 少数・クリティカルパスのみ
       /------\
      /  結合   \    ← 中程度・API/DB/モジュール間
     /----------\
    /    単体     \  ← 多数・ロジック・純粋関数中心
   /--------------\

レベル	割合の目安	実行速度	保守コスト
単体	70%	高速(ms)	低
結合	20%	中速(秒)	中
E2E	10%	低速(分)	高

逆ピラミッドの弊害: E2Eに偏重すると実行時間が膨大になり、フレーキーテストが増え、失敗箇所の特定が困難になる。

単体テスト

AAAパターン

// Arrange: テスト対象の状態を準備する
// Act: テスト対象のコードを実行する
// Assert: 結果を検証する

• 1テスト1検証を原則とする(assertは1〜2個まで)
• テスト名は仕様を表す日本語/文で記述する
  • 悪い例: test_calc, testError
  • 良い例: 割引率が0のとき税込価格と定価が等しい, 在庫数が0の場合は注文できない

境界値分析

境界	チェック対象
0	ゼロ除算・空判定
1	最小有効値
最大値	制限値ちょうど
最大値+1	制限超過
null/undefined	未入力・存在しない
空文字・空配列	空コレクション

同値分割

• 「正常系クラス」「異常系クラス」「境界クラス」でそれぞれ代表値を1つ選ぶ
• クラス内の値はどれも同じ振る舞いをすると仮定し、テストを重複させない

モックの方針

• 外部I/O(DB・API・ファイル・時刻・乱数)のみモックする
• ビジネスロジックは実物を使う
• モックしすぎの害: モックが増えると「実装のコピー」になり、リファクタリングで壊れやすくなる

結合テスト

• モジュール間インタフェース、API、DBを実物(またはTestcontainers)で検証する
• テストデータ管理
  • テストごとにデータを用意し、テスト後にロールバックまたは削除する
  • シードデータは最小限に留める
• テスト間の独立性
  • 実行順序に依存するテストは禁止
  • 共有状態(グローバル変数・共通DB行)を変更する場合は必ず元に戻す
• APIテストは正常系・エラー系・認証/認可をカバーする

E2Eテスト

対象の絞り込み

クリティカルユーザージャーニー(CUJ)のみに限定する:

• ユーザー登録 → ログイン
• 主要操作(商品検索 → カート → 決済 など)
• 管理者による重要設定変更

フレーキー対策

• 明示的待機: sleep 禁止。要素の表示・状態変化を条件として待機する
• テストID付与: UIセレクタは data-testid 属性を使い、CSSクラスやテキストに依存しない
• 環境分離: テスト専用アカウント・テストデータを用意し、本番データに依存しない
• リトライ設定: CIでは最大2回リトライを許容するが、原因究明を先延ばしにしない

CI実行時間とのトレードオフ

• E2EはPRマージ前ではなく、mainへのマージ後(夜間CIなど)に実行するのも現実的な選択肢
• 10分を超えるE2Eスイートは見直しのサイン

進め方

1. 受け入れ基準の確認 — [[requirements-definition]] の受け入れ基準をインプットとして取り込む
2. テスト観点表の作成 — 機能ごとに正常・境界・異常・権限の4観点で洗い出す
3. レベル割り当て — 各ケースを単体/結合/E2Eに振り分け、自動化有無を決める
4. 単体テストから実装 — ロジックを先にカバーし、早期フィードバックを得る
5. 結合テストで接続を検証 — API・DB・外部サービスとのインタフェースを確認する
6. E2Eでシナリオを確認 — CUJが通ることをブラウザ/CLIで確認する
7. カバレッジ確認 — 未カバー箇所を確認し、重要なロジックが漏れていないか検査する
8. CIへの組み込み — 単体・結合はPRごと、E2EはmainマージorスケジュールCIで実行する

成果物テンプレート

テスト観点表(コードブロックはMarkdownテーブル形式で出力する):

| 機能 | 観点 | テストケース | 期待結果 | レベル | 自動化 |
|---|---|---|---|---|---|
| ログイン | 正常 | 正しいID/PWで送信する | ダッシュボードに遷移する | E2E | 有 |
| ログイン | 異常 | 誤ったPWで3回送信する | アカウントがロックされる | 結合 | 有 |
| ログイン | 境界 | PWが最大文字数ちょうどで送信する | ログイン成功する | 単体 | 有 |
| ログイン | 権限 | 未ログイン状態で/dashboardにアクセスする | ログインページにリダイレクトされる | 結合 | 有 |
| 商品検索 | 正常 | キーワードを入力して検索する | 該当商品一覧が表示される | 結合 | 有 |
| 商品検索 | 境界 | 検索結果が0件のとき | 「該当なし」メッセージが表示される | 単体 | 有 |
| 商品検索 | 異常 | DBが応答しないとき | 503エラー画面が表示される | 結合 | 有 |
| 決済 | 正常 | 有効なカードで決済を完了する | 注文確認メールが送信される | E2E | 有 |
| 決済 | 異常 | カード残高不足で決済する | エラーメッセージが表示され注文が保存されない | 結合 | 有 |

チェックリスト

• テストピラミッドの比率が適切か(E2E偏重になっていないか)
• テスト名が仕様を表す文章になっているか
• AAAパターンに沿って書かれているか
• 境界値(0/1/最大/最大+1/null/空)がカバーされているか
• モックが外部I/Oのみに限定されているか
• 結合テストでテスト間の順序依存がないか
• E2Eにフレーキーなsleepが含まれていないか
• E2Eがdata-testidを使ってセレクタを記述しているか
• バグ修正時に再現テストが先に書かれているか
• カバレッジレポートで重要ロジックの未カバーがないか
• CIに組み込まれ自動で実行されるか

アンチパターン

アンチパターン	何が問題か	対処
実装の内部構造に密結合したテスト	リファクタリングのたびにテストが壊れる	公開インタフェース(入出力・振る舞い)でテストする
モックだらけで何も検証していないテスト	モックが正しく設定されているかをテストしているだけになる	外部I/Oのみモックし、ロジックは実物を使う
フレーキーテストの放置	CI信頼性が失われ、失敗を無視するようになる	原因を特定して即修正するか、一時スキップして追跡チケットを立てる
カバレッジ稼ぎ(テストのためのテスト)	意味のないassertでカバレッジを水増しする	カバレッジは「未テスト箇所の発見ツール」として使い、100%を目標にしない
E2E過多の逆ピラミッド	実行時間が膨大、失敗箇所の特定が困難	結合・単体に落とせるケースをE2Eから移動する
テスト間の共有状態	実行順序によって結果が変わる	テストごとにデータを独立させ、後処理で必ずリセットする
sleep による待機	環境速度依存でフレーキーになる	条件待機(waitFor/waitUntil)に置き換える

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

モデル	役割の目安
司令塔	テスト戦略の立案・テスト観点表のレビュー・カバレッジ分析結果の評価・テスト方針の最終判断
Opus	複雑なテスト設計(並行処理・外部サービス連携)・フレーキーテストの根本原因調査・テストアーキテクチャのリファクタリング設計
Sonnet	テストコードの実装・テスト観点表からのケース展開・モック設計・カバレッジレポートの確認と補強
Haiku	テスト実行と結果収集・ログの一次解析・テストファイルの探索・テンプレートからのボイラープレート生成

関連スキル

• [[requirements-definition]] — 受け入れ基準をテストケースに落とし込む起点
• [[implementation]] — テストと実装を並行して進める際の実装側のガイド
• [[detailed-design]] — テスト対象のインタフェース・境界の設計情報を参照
• [[architecture-design]] — テスト容易性(Testability)を考慮した構造設計
• [[orchestration]] — モデル委譲の共通原則
• [[task-breakdown]] — テスト実装タスクの分解と並列化
• [[mvp-development]] — MVP段階でのテスト範囲の絞り込み