testing-strategy-builder

テスト戦略ビルダー

概要

このスキルでは、ソフトウェアの品質、信頼性、保守性を確保する効果的なテスト戦略を構築するための包括的なガイダンスを提供します。ゼロから始める場合も、既存のテストカバレッジを改善する場合も、このフレームワークはチームが堅牢なテストアプローチを設計するのに役立ちます。

このスキルを使用する場面：

• 新しいプロジェクトや機能のテスト戦略を計画するとき
• 既存のコードベースのテストカバレッジを改善するとき
• 品質ゲートとカバレッジ目標を設定するとき
• テスト自動化アーキテクチャを設計するとき
• テスト計画やテストケースを作成するとき
• 適切なテストツールやフレームワークを選ぶとき
• CI/CD パイプラインで継続的テストを導入するとき

同梱リソース：

• references/code-examples.md - 詳細なテストコードの例
• templates/test-plan-template.md - 包括的なテスト計画テンプレート
• templates/test-case-template.md - テストケース文書テンプレート
• checklists/test-coverage-checklist.md - カバレッジ確認チェックリスト

必要なツール

このスキルでは、以下のテストツールを参照します。すべてのツールが必要なわけではありません。プロジェクトに適したツールをスキルが推奨します。

JavaScript/TypeScript のテスト

• Jest： 最も人気のあるテストフレームワーク

  • インストール： npm install --save-dev jest @types/jest
  • 設定： npx jest --init

• Vitest： Vite ネイティブのテストフレームワーク

  • インストール： npm install --save-dev vitest
  • 設定： vite.config.ts に追加します

• Playwright： エンドツーエンドテスト

  • インストール： npm install --save-dev @playwright/test
  • セットアップ： npx playwright install

• k6： パフォーマンステスト

  • インストール（macOS）： brew install k6
  • インストール（Linux）： k6.io からダウンロードします
  • コマンド： k6 run script.js

Python のテスト

• pytest： 標準的な Python テストフレームワーク

  • インストール： pip install pytest
  • コマンド： pytest

• pytest-cov： カバレッジレポート

  • インストール： pip install pytest-cov
  • コマンド： pytest --cov=.

• Locust： パフォーマンステスト

  • インストール： pip install locust
  • コマンド： locust -f locustfile.py

カバレッジツール

• c8： JavaScript/TypeScript のカバレッジ

  • インストール： npm install --save-dev c8
  • コマンド： c8 npm test

• Istanbul/nyc： 代替の JS カバレッジツール

  • インストール： npm install --save-dev nyc
  • コマンド： nyc npm test

インストールの確認

# JavaScript/TypeScript
jest --version
vitest --version
playwright --version
k6 version

# Python
pytest --version
locust --version

# Coverage
c8 --version
nyc --version

注： このスキルでは、プロジェクトのフレームワーク（React、Vue、FastAPI、Django など）とテストのニーズに基づいて、ツールの選定を案内します。

テストの理念

テストトロフィー 🏆

現代のテストでは、テストピラミッドから発展した「テストトロフィー」モデルに従います。

         🏆
       /    \
      /  E2E  \         ← Few (critical user journeys)
     /----------\
    / Integration\      ← Many (component interactions)
   /--------------\
  /     Unit       \    ← Most (business logic)
 /------------------\
/  Static Analysis   \  ← Foundation (linting, type checking)

原則：

1. 静的解析：実行前に構文エラー、型の問題、よくあるバグを検出します
2. 単体テスト：個々の関数やコンポーネントを分離してテストします
3. 統合テスト：コンポーネントが連携して動作するかをテストします
4. E2E テスト：重要なユーザーワークフローをエンドツーエンドで検証します

バランス： 統合テスト 70％、単体テスト 20％、E2E テスト 10％（状況に応じて調整してください）

---

テスト戦略のフレームワーク

1. カバレッジ目標

推奨目標：

• コード全体のカバレッジ： 最低 80％
• 重要な処理経路： 95～100％（決済、認証、データ変更）
• 新機能： カバレッジ 100％を必須とします
• ビジネスロジック： 90％以上のカバレッジ
• UI コンポーネント： 70％以上のカバレッジ

カバレッジの種類：

• 行カバレッジ： 実行されたコード行の割合
• 分岐カバレッジ： 実行された条件分岐の割合
• 関数カバレッジ： 呼び出された関数の割合
• ステートメントカバレッジ： 実行されたステートメントの割合

重要： カバレッジは指標であり、目標ではありません。カバレッジ 100％ ≠ バグのないコードです。

2. テストの分類

静的解析

目的：実行前にエラーを検出します
ツール：ESLint、Prettier、TypeScript、Pylint、mypy、Ruff
実行タイミング： コミット前フック、CI パイプライン

単体テスト

目的：分離されたビジネスロジックをテストします ツール：Jest、Vitest、pytest、JUnit 特徴：

• 実行が高速（テストあたり 100ms 未満）
• 外部依存なし（データベース、API、ファイルシステム）
• 決定論的（同じ入力 = 同じ出力）
• 単一の責務をテストします

**カバレッジ目標：**ビジネスロジックで 90% 以上

詳細な単体テストの例については、references/code-examples.md を参照してください。

統合テスト

目的：コンポーネント間の連携をテストします **ツール：**Testing Library、Supertest、フィクスチャを使った pytest 特徴：

• 複数のユニットが連携して動作することをテストします
• テスト用データベースやモック化した外部サービスを使用する場合があります
• 実行時間は中程度（テストあたり 1s 未満）
• インターフェースとコントラクトに重点を置きます

**カバレッジ目標：**API エンドポイントとコンポーネント間の連携で 70% 以上

API 統合テストの例については、references/code-examples.md を参照してください。

エンドツーエンド（E2E）テスト

目的：重要なユーザージャーニーを検証します **ツール：**Playwright、Cypress、Selenium 特徴：

• アプリケーション全体のフロー（フロントエンド + バックエンド + データベース）をテストします
• 実行が低速（テストあたり 5～30s）
• 本番環境に近い環境で実行します
• ビジネス上重要な経路に重点を置きます

**カバレッジ目標：**重要なユーザージャーニーを 5～10 件

E2E テストの完全な例については、references/code-examples.md を参照してください。

パフォーマンステスト

目的：負荷がかかった状態でのシステムパフォーマンスを検証します **ツール：**k6、Artillery、JMeter、Locust 種類：

• 負荷テスト：想定される負荷下でのシステム動作
• ストレステスト：限界点の特定
• スパイクテスト：急激なトラフィック増加への対応
• ソークテスト：長時間にわたる継続的な負荷（メモリリーク）

**カバレッジ目標：**パフォーマンスが重要なすべてのエンドポイントをテストします

k6 による負荷テストの例については、references/code-examples.md を参照してください。

---

テスト計画

1. リスクベーステスト

リスク評価に基づいてテストの優先順位を決めます。

高リスク（100% のカバレッジが必須）：

• 決済処理
• 認証と認可
• データの変更（作成、更新、削除）
• セキュリティ上重要な操作
• コンプライアンス関連機能

中リスク（80% のカバレッジ）：

• ビジネスロジック
• データ変換
• API 統合
• メール／通知システム

低リスク（50% のカバレッジ）：

• UI のスタイリング
• 静的コンテンツ
• 読み取り専用の操作
• 重要度の低い機能

2. テストケースの設計

Given-When-Then パターン：

Given [initial context]
When [action occurs]
Then [expected outcome]

このパターンを使うと、テストが明確になり、焦点を絞れます。実装例については、references/code-examples.md を参照してください。

3. テストデータの管理

戦略：

• フィクスチャ：JSON/YAML ファイルに事前定義されたテストデータ
• ファクトリー：プログラムでテストデータを生成します
• シーダー：既知のデータをテスト用データベースに投入します
• Faker ライブラリ：現実的なランダムデータを生成します

テストファクトリーとフィクスチャの例については、references/code-examples.md を参照してください。

---

テストパターンとベストプラクティス

1. AAA パターン（Arrange-Act-Assert）

テストを明確な 3 つのフェーズに分けて構成します。

• Arrange：テストデータとコンテキストを準備します
• Act：テスト対象の操作を実行します
• Assert：期待される結果を検証します

AAA パターンの詳しい例については、references/code-examples.md を参照してください。

2. テストの独立性

各テストは独立している必要があります：

• テストごとに新しいテスト用データベースを使用します
• 各テストの後にリソースをクリーンアップします
• テストの実行順序に依存しないようにします

テストの独立性を保つパターンについては、references/code-examples.md を参照してください。

3. モックと実際の依存関係

モックを使う場合：

• 外部 API（決済ゲートウェイ、サードパーティサービス）
• 時間のかかる処理（ファイル I/O、ネットワーク呼び出し）
• 非決定的な動作（現在時刻、ランダム値）
• テストが難しいシナリオ（エラー条件、エッジケース）

実際の依存関係を使う場合：

• 高速で決定論的な処理
• 重要なビジネスロジック
• データベース操作（テスト用データベースを使用）
• 内部サービス間の連携

モックの例については、references/code-examples.md を参照してください。

4. スナップショットテスト

用途： UI コンポーネント、API レスポンス、生成コード

警告： スナップショットは壊れやすくなることがあります。変更が頻繁な UI ではなく、安定したコンポーネントに使用してください。

5. パラメーター化テスト

データテーブルを使用して、同じロジックで複数のシナリオをテストします。

パラメーター化テストのパターンについては、references/code-examples.md を参照してください。

---

継続的テスト

1. CI/CD 統合

パイプラインのステージ：

# Example: GitHub Actions
name: Test Pipeline

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm ci
      - name: Lint
        run: npm run lint
      - name: Type check
        run: npm run typecheck
      - name: Unit & Integration Tests
        run: npm test -- --coverage
      - name: Upload coverage
        uses: codecov/codecov-action@v3
      - name: E2E Tests
        run: npm run test:e2e
      - name: Performance Tests (on main branch)
        if: github.ref == 'refs/heads/main'
        run: npm run test:performance

2. 品質ゲート

次の場合はマージ／デプロイをブロックします：

• コードカバレッジがしきい値を下回った場合（例：80%）
• テストが1つでも失敗した場合
• lint エラーがある場合
• パフォーマンスの低下が検出された場合（10% 超の低下）
• セキュリティの脆弱性が見つかった場合

3. テスト実行戦略

コミットのたびに実行：

• 静的解析（lint、型チェック）
• 単体テスト
• 高速な統合テスト（合計 5 分未満）

プルリクエスト時：

• すべてのテスト（単体＋統合＋E2E）
• カバレッジレポート
• パフォーマンスベンチマーク

ステージング環境へのデプロイ時：

• E2E テストスイート全体
• 負荷テスト
• セキュリティスキャン

本番環境へのデプロイ時：

• スモークテスト（重要な経路のみ）
• ヘルスチェック
• モニタリングを伴うカナリアデプロイ

---

テストツールの推奨

JavaScript/TypeScript

カテゴリ	ツール	用途
単体／統合	Vitest	高速、Vite ネイティブ、モダン
単体／統合	Jest	成熟しており、エコシステムが充実
E2E	Playwright	クロスブラウザー、信頼性が高く、高速
E2E	Cypress	開発者に使いやすく、視覚的なデバッグに対応
コンポーネントテスト	Testing Library	ユーザー中心、フレームワークに依存しない
API テスト	Supertest	HTTP アサーション、Express 統合
パフォーマンス	k6	負荷テスト、スクリプト化可能

Python

カテゴリ	ツール	用途
単体／統合	pytest	高機能、拡張可能、フィクスチャに対応
API テスト	httpx + pytest	非同期処理に対応、モダン
E2E	Playwright (Python)	ブラウザーの自動化
パフォーマンス	Locust	負荷テスト、Python ベース
モック	unittest.mock	標準ライブラリ、信頼性が高い

---

よくあるテストのアンチパターン

❌ 実装の詳細をテストする

// Bad: Testing internal state
expect(component.state.isLoading).toBe(false);

// Good: Testing user-visible behavior
expect(screen.queryByText('Loading...')).not.toBeInTheDocument();

❌ コードとの結合度が高すぎるテスト

// Bad: Test breaks when implementation changes
expect(userService.save).toHaveBeenCalledTimes(1);

// Good: Test behavior, not implementation
const user = await db.users.findOne({ email: '[email protected]' });
expect(user).toBeTruthy();

❌ 不安定なテスト

// Bad: Non-deterministic timeout
await waitFor(() => {
  expect(screen.getByText('Success')).toBeInTheDocument();
}, { timeout: 1000 }); // Might fail on slow CI

// Good: Use explicit waits with longer timeout
await screen.findByText('Success', {}, { timeout: 5000 });

❌ 巨大なテストケース

// Bad: One test does too much
test('user workflow', async () => {
  // 100 lines testing signup, login, profile update, logout...
});

// Good: Focused tests
test('user can sign up', async () => { /* ... */ });
test('user can login', async () => { /* ... */ });
test('user can update profile', async () => { /* ... */ });

---

エージェントとの連携

コード品質レビュアー

• テストカバレッジレポートを確認します
• 不足しているテストケースを提案します
• テストの品質と構成を検証します
• テストがこのスキルのパターンに従っていることを確認します

バックエンドシステムアーキテクト

• サービスの設計時にテスト戦略のテンプレートを使用します
• API がテスト可能であることを確認します（依存性注入、明確なインターフェース）
• 統合テストのアーキテクチャを計画します

フロントエンド UI デベロッパー

• コンポーネントテストのパターンを適用します
• Testing Library のベストプラクティスを使用します
• ユーザーフローの E2E テストを実装します

AI/ML エンジニア

• ML モデルに合わせてテストパターンを調整します（データ検証、モデルのパフォーマンステスト）
• 推論エンドポイントのパフォーマンステストを使用します

---

クイックスタートチェックリスト

新しいプロジェクトや機能を開始するとき：

• カバレッジの目標を定める（全体、重要な経路、新規コード）
• テストフレームワークを選択する（Jest/Vitest、Playwright など）
• テスト用のインフラストラクチャを設定する（テストデータベース、フィクスチャ、ファクトリー）
• テスト計画を作成する（templates/test-plan-template.md を参照）
• 静的解析を導入する（ESLint、TypeScript）
• ビジネスロジックの単体テストを作成する（カバレッジ 80% 以上）
• API エンドポイントの統合テストを作成する（カバレッジ 70% 以上）
• 重要なユーザージャーニーの E2E テストを作成する（5～10 フロー）
• 品質ゲートを備えた CI/CD パイプラインを構成する
• カバレッジレポートを設定する（Codecov、Coveralls）
• プロジェクトの README にテスト規約を記載する

詳細なコード例： references/code-examples.md を参照してください。

---

スキルのバージョン：1.0.0
最終更新日：2025-10-31
メンテナンス担当：AI Agent Hub Team