testing-strategies

テスト戦略

単体テスト、統合テスト、E2E テスト、コントラクトテストの各レベルで適切なテスト手法を戦略的に選択・実装し、包括的で効果的なテストスイートを構築します。

目的

このスキルでは、以下のための戦略的なフレームワークを提供します。

• テスト種別の選択：単体テスト、統合テスト、E2E テスト、コントラクトテストのどれを使うかを判断します
• テストピラミッドのバランス調整：迅速なフィードバックと信頼性の高いカバレッジを実現するテスト配分を最適化します
• 複数言語での実装：TypeScript、Python、Go、Rust で一貫したテストパターンを適用します
• テストデータ管理：適切な手法（フィクスチャ、ファクトリー、プロパティベーステスト）を選択します
• CI/CD との統合：最適な実行パターンで、テストを自動化パイプラインに統合します

テストは、信頼性の高いソフトウェアの基盤です。マイクロサービスアーキテクチャと継続的デリバリーが2025年に標準となる中、複数のレベルにわたる戦略的なテストは、これまで以上に重要です。

このスキルを使用するタイミング

以下の場合にこのスキルを呼び出します。

• テストカバレッジが必要な新機能を構築するとき
• 新しいプロジェクトのテスト戦略を設計するとき
• 既存のテストをリファクタリングして、速度や信頼性を向上させるとき
• テスト工程を含む CI/CD パイプラインを設定するとき
• 単体テスト、統合テスト、E2E テストのどの手法を使うか選択するとき
• マイクロサービス向けにコントラクトテストを実装するとき
• フィクスチャ、ファクトリー、プロパティベーステストを使ってテストデータを管理するとき

テストピラミッドのフレームワーク

中心となる考え方

テストピラミッドは、速度と信頼性を最適化するためのテスト配分を示します。

         /\
        /  \  E2E Tests (10%)
       /----\  - Slow but comprehensive
      /      \  - Full stack validation
     /--------\
    /          \  Integration Tests (20-30%)
   /            \  - Moderate speed
  /--------------\  - Component interactions
 /                \
/------------------\  Unit Tests (60-70%)
                      - Fast feedback
                      - Isolated units

重要な原則：単体テスト（高速で分離されている）は多く、E2E テスト（低速で包括的）は少なくします。統合テストはその間をつなぎます。

現代的な適応（2025年）

マイクロサービスに合わせた調整：

• 単体テストと統合テストの間にコントラクトテスト層を追加します
• 統合テスト／コントラクトテストを30％に増やします（サービス境界を検証します）
• E2E テストは重要なユーザージャーニーのみに絞ります

クラウドネイティブのパターン：

• 統合テストにコンテナを使用します（一時的なデータベース、テストサービス）
• CI/CD のフィードバックを迅速化するために並列実行します
• リスクベースでテストの優先順位を決めます（影響の大きい領域に注力します）

ピラミッドの詳細な指針については、references/testing-pyramid.md を参照してください。

汎用テスト判断ツリー

どのテスト種別を使うべきですか？

START: Need to test [feature]

Q1: Does this involve multiple systems/services?
  ├─ YES → Q2
  └─ NO  → Q3

Q2: Is this a critical user-facing workflow?
  ├─ YES → E2E Test (complete user journey)
  └─ NO  → Integration or Contract Test

Q3: Does this interact with external dependencies (DB, API, filesystem)?
  ├─ YES → Integration Test (real DB, mocked API)
  └─ NO  → Q4

Q4: Is this pure business logic or a pure function?
  ├─ YES → Unit Test (fast, isolated)
  └─ NO  → Component or Integration Test

テスト種別の選択例

機能	テスト種別	理由
calculateTotal(items)	単体	純粋関数で、依存関係がありません
POST /api/users エンドポイント	統合	API とデータベースのやり取りをテストします
ユーザー登録フロー（フォーム → API → リダイレクト）	E2E	重要なユーザージャーニーであり、フルスタックを対象とします
マイクロサービス A → B の通信	コントラクト	サービスインターフェースを検証します
formatCurrency(amount, locale)	単体＋プロパティ	純粋なロジックで、多くのエッジケースがあります
フォームの検証ロジック	単体	分離されたビジネスルールです
S3 へのファイルアップロード	統合	外部サービスとのやり取りをテストします

包括的な判断フレームワークについては、references/decision-tree.md を参照してください。

テストレベルの詳細

単体テスト（基盤 - 60～70％）

目的：小さく分離されたコード単位（関数、メソッド、コンポーネント）を検証します

特徴：

• 高速（テストあたり数ミリ秒）
• 分離されている（外部依存関係がない）
• 決定論的（同じ入力なら同じ出力）
• 広範囲をカバーする（テスト数は多く、各テストの対象範囲は小さい）

使用する場面：

• 純粋関数（入力 → 出力）
• ビジネスロジックとアルゴリズム
• ユーティリティ関数
• コンポーネントのレンダリング（統合なし）
• 検証ロジック

推奨ツール：

• TypeScript/JavaScript：Vitest（主要な選択肢。Jest より10倍高速）、Jest（レガシー）
• Python：pytest（業界標準）
• Go：testing パッケージ（標準ライブラリ）＋ testify（アサーション）
• Rust：cargo test（標準ライブラリ）

詳細なパターンについては、references/unit-testing-patterns.md を参照してください。

統合テスト（中間層 - 20～30%）

目的：コンポーネント、モジュール、サービス間の連携を検証します

特徴：

• 中程度の速度（1テストあたり数秒）
• 部分的な統合（実際のデータベースを使用し、外部 API はモック化）
• 限定的な範囲（コンポーネントの境界をテスト）
• API とデータベースの検証

使用する場面：

• API エンドポイント（リクエスト → レスポンス）
• データベース操作（CRUD、クエリ）
• サービス間通信
• イベントハンドラーとメッセージ処理
• ファイル I/O 操作

推奨ツール：

• TypeScript/JavaScript：Vitest + MSW（API のモック化）、Supertest（HTTP テスト）
• Python：pytest + pytest-httpserver、pytest-postgresql
• Go：testing + httptest、testcontainers
• Rust：cargo test + mockito、testcontainers

詳細なパターンについては、references/integration-testing-patterns.md を参照してください。

エンドツーエンドテスト（最上位層 - 10%）

目的：アプリケーションスタック全体を通じたユーザーワークフローを検証します

特徴：

• 低速（テストスイートあたり数分）
• 完全な統合（実際のブラウザー、サービス、データベース）
• 広範な範囲（開始から完了までのユーザージャーニー）
• 不安定になりやすい（慎重な設計が必要）

使用する場面：

• 重要なユーザージャーニー（ログイン、購入手続き、支払い）
• クロスブラウザー互換性の検証
• 統合テストではカバーされない実環境のシナリオ
• コア機能のリグレッション防止

ベストプラクティス：

• E2E テストは価値の高いシナリオに限定します（あらゆるエッジケースを対象にしない）
• 安定したセレクターを使用します（CSS クラスではなく data-testid）
• ネットワークの不安定さに備えてリトライロジックを実装します
• 速度を上げるためにテストを並列実行します

推奨ツール：

• すべての言語：Playwright（クロスブラウザー対応、高速、Microsoft が支援）

詳細なパターンについては、references/e2e-testing-patterns.md を参照してください。

コントラクトテスト（マイクロサービス）

目的：完全な統合を行わずに、サービスインターフェースと API コントラクトを検証します

使用する場面：

• マイクロサービスアーキテクチャ
• サービス間通信
• API コントラクトの検証
• E2E テストのオーバーヘッド削減

推奨ツール：Pact（pact.io）— TypeScript、Python、Go、Rust に対応

詳細なパターンについては、references/contract-testing.md を参照してください。

テストデータ管理戦略

各アプローチを使用する場面

フィクスチャ（静的データ）：

• メリット：決定論的で、デバッグが容易
• デメリット：古くなる可能性があり、多様性をテストできない
• 使用する場面：既知のシナリオのテスト、リグレッションテスト

ファクトリー（生成データ）：

• メリット：柔軟性があり、多様なデータを生成できる
• デメリット：決定性が低く、デバッグが難しい
• 使用する場面：多様なテストデータが必要な場合、エッジケースのテスト

プロパティベーステスト（ランダムデータ）：

• メリット：想定していなかったエッジケースを発見できる
• デメリット：時間がかかる場合があり、失敗の再現が難しい
• 使用する場面：複雑なアルゴリズム、パーサー、バリデーター

推奨される組み合わせ：

• 単体テスト：フィクスチャ（既知の入力値）+ プロパティベーステスト（エッジケース）
• 統合テスト：ファクトリー（柔軟なデータ）+ データベースのシーディング
• E2E テスト：フィクスチャ（再現可能なシナリオ）

プロパティベーステストツール：

• TypeScript/JavaScript：fast-check
• Python：hypothesis（クラス最高水準）
• Go：gopter
• Rust：proptest（主要ツール）

詳細な戦略については、references/test-data-strategies.md を参照してください。

モック化の判断マトリクス

モックを使う場合と実際の依存関係を使う場合

依存関係	単体テスト	統合テスト	E2E テスト
データベース	モック（インメモリ）	実物（テスト DB、Docker）	実物（ステージング DB）
外部 API	モック（MSW、nock）	モック（MSW、VCR）	実物（またはステージング）
ファイルシステム	モック（インメモリ FS）	実物（一時ディレクトリ）	実物
時刻/日付	モック（freezeTime）	モック（決定的な場合）	実物（通常）
環境変数	モック（setEnv）	モック（テスト設定）	実物（テスト環境）
内部サービス	モック（スタブ）	実物（またはコンテナ）	実物

基本原則:

1. 単体テスト: 外部のものはすべてモックする
2. 統合テスト: 実際のデータベース（エフェメラル）を使い、外部 API はモックする
3. E2E テスト: すべて実物（またはステージング相当）を使う
4. コントラクトテスト: 何もモックしない（実際のインターフェースをテストする）

詳細なモックのパターンについては、references/mocking-strategies.md を参照してください。

言語別クイックスタート

TypeScript/JavaScript

Vitest による単体テスト:

import { describe, test, expect } from 'vitest'

test('calculates total with tax', () => {
  const items = [{ price: 10, quantity: 2 }]
  expect(calculateTotal(items, 0.1)).toBe(22)
})

MSW による統合テスト:

import { setupServer } from 'msw/node'
import { http, HttpResponse } from 'msw'

const server = setupServer(
  http.get('/api/user/:id', ({ params }) => {
    return HttpResponse.json({ id: params.id, name: 'Test User' })
  })
)

Playwright による E2E テスト:

import { test, expect } from '@playwright/test'

test('user can checkout', async ({ page }) => {
  await page.goto('https://example.com')
  await page.getByRole('button', { name: 'Add to Cart' }).click()
  await expect(page.getByText('1 item in cart')).toBeVisible()
})

完全な動作例については examples/typescript/ を参照してください。

Python

pytest による単体テスト:

def test_calculate_total_with_tax():
    items = [{"price": 10, "quantity": 2}]
    assert calculate_total(items, tax_rate=0.1) == 22

hypothesis によるプロパティベーステスト:

from hypothesis import given, strategies as st

@given(st.lists(st.integers()))
def test_reverse_reverse_is_identity(lst):
    assert reverse(reverse(lst)) == lst

完全な動作例については examples/python/ を参照してください。

Go と Rust

これらの言語の完全な動作例については、examples/go/ と examples/rust/ を参照してください。

カバレッジと品質メトリクス

意味のあるカバレッジ目標

推奨目標:

• 重要なビジネスロジック: カバレッジ 90% 以上
• API エンドポイント: カバレッジ 80% 以上
• ユーティリティ関数: カバレッジ 70% 以上
• UI コンポーネント: カバレッジ 60% 以上（マークアップではなくロジックに注目）
• プロジェクト全体: カバレッジ 70〜80%

アンチパターン: カバレッジ 100% を目指すと、些末なコードをテストすることになり、誤った自信につながります。

カバレッジツール:

• TypeScript/JavaScript: Vitest coverage（c8/istanbul）
• Python: pytest-cov
• Go: go test -cover
• Rust: cargo-tarpaulin

ミューテーションテスト（テスト品質の検証）

ミューテーションテストはバグを注入し、テストがそれを検出できるかを検証します。

ツール:

• TypeScript/JavaScript: Stryker Mutator
• Python: mutmut
• Go: go-mutesting
• Rust: cargo-mutants

詳細なカバレッジ戦略については、references/coverage-strategies.md を参照してください。

CI/CD 統合パターン

高速フィードバックループ戦略

ステージ 1: プリコミット（30 秒未満）

• Lint とフォーマットのチェック
• 単体テスト（重要なパスのみ）

ステージ 2: コミット時（2 分未満）

• すべての単体テスト
• 静的解析

ステージ 3: プルリクエスト（5 分未満）

• 統合テスト
• カバレッジのレポート

ステージ 4: マージ前（10 分未満）

• E2E テスト（重要なパス）
• クロスブラウザテスト

並列実行

テスト実行の高速化:

• Vitest: vitest --threads
• Playwright: playwright test --workers=4
• pytest: pytest -n auto（pytest-xdist が必要）
• Go: go test -parallel 4

避けるべき一般的なアンチパターン

アイスクリームコーン（逆ピラミッド）

問題: E2E テストが多すぎて、単体テストが少なすぎる 結果: 遅いテストスイート、不安定なテスト、長いフィードバックループ 解決策: 単体テストを増やし、E2E テストを減らす方向に再バランスする

実装の詳細をテストする

問題: テストが振る舞いではなく内部構造に結合している 解決策: 実装ではなく振る舞い（入力 → 出力）をテストする

統合テストでの過剰なモック

問題: すべてをモックすると統合テストの目的が損なわれる 解決策: 実際のデータベース（エフェメラル）を使い、外部 API のみをモックする

不安定な E2E テスト

問題: タイミングの問題によりテストが断続的に失敗する 解決策:

• 自動待機機能を使う（Playwright には自動待機が組み込まれています）
• ハードコードされた待機（sleep(1000)）を避ける
• 安定したセレクタ（data-testid）を使う
• ネットワークリクエストにリトライロジックを実装する

他のスキルとの連携

フォームのテスト：フォーム固有の検証や送信テストのパターンについては、building-forms スキルを参照してください。

API のテスト：REST／GraphQL エンドポイントのテストや契約検証については、api-patterns スキルを参照してください。

CI/CD パイプライン：テストの自動化、並列実行、カバレッジレポートについては、building-ci-pipelines スキルを参照してください。

データ可視化のテスト：チャート設定のスナップショットテストやビジュアルリグレッションテストについては、visualizing-data スキルを参照してください。

リファレンスドキュメント

特定のトピックをさらに詳しく調べるには、以下を参照してください。

• references/testing-pyramid.md - テストピラミッドのフレームワークとバランスを取るための戦略の詳細
• references/decision-tree.md - テストタイプを選択するための包括的な意思決定フレームワーク
• references/unit-testing-patterns.md - 各言語におけるユニットテストのパターン
• references/integration-testing-patterns.md - データベース、API、コンテナーを使った統合テスト
• references/e2e-testing-patterns.md - E2E テストのベストプラクティスと Playwright のパターン
• references/contract-testing.md - Pact を使ったコンシューマー主導の契約テスト
• references/test-data-strategies.md - フィクスチャ、ファクトリー、プロパティベーステスト
• references/mocking-strategies.md - 依存関係をモックするタイミングと方法
• references/coverage-strategies.md - 意味のあるカバレッジ指標とミューテーションテスト

動作するサンプル

完全で実行可能なコードサンプルを examples/ ディレクトリで利用できます。

• examples/typescript/ - Vitest のユニット／統合テスト、Playwright の E2E、MSW によるモック、fast-check によるプロパティベーステスト
• examples/python/ - pytest のユニット／統合テスト、フィクスチャ、Playwright の E2E、hypothesis によるプロパティベーステスト
• examples/go/ - 標準ライブラリのテスト、testify のアサーション、httptest による統合テスト
• examples/rust/ - cargo test によるユニットテスト、proptest によるプロパティベーステスト、統合テストのパターン

すべてのサンプルには、依存関係、使用方法、エラー処理が含まれています。