testing-strategy

テスト戦略

概要

プロジェクトの状況を分析し、包括的なテスト戦略を提案します。このスキルでは、適切なフレームワークを選択し、テストピラミッドを定義して、カバレッジのしきい値を設定し、テスト設定ファイルを生成します。目標は、チームが維持できる、再現可能で測定可能なテスト基盤を構築することです。

開始時に次のように伝えます：「テスト方針を定義するため、testing-strategy スキルを使用します。」

---

フェーズ 1：プロジェクトの分析

目標： 推奨を行う前に、現在の技術スタック、既存のテスト、CI の設定を把握します。

作業

1. 技術スタック（言語、フレームワーク、ランタイム）を特定します
2. 既存のテストを調査します（現在どのようなテストがあるか）
3. CI/CD パイプラインを確認します（テストの実行方法）
4. 現在のカバレッジレベルを測定します
5. 外部依存関係（サービス、データベース、API）を整理します

調査コマンド

# Identify test files
find . -name "*.test.*" -o -name "*.spec.*" | head -30

# Check for test config
ls vitest.config.* jest.config.* pytest.ini pyproject.toml .mocharc.* 2>/dev/null

# Check current coverage
cat coverage/coverage-summary.json 2>/dev/null || echo "No coverage report found"

# Check CI config
cat .github/workflows/*.yml 2>/dev/null | head -50

停止 — 次の条件を満たすまでフェーズ 2 に進まないでください：

• 技術スタックが特定されている
• 既存のテストインフラストラクチャが整理されている
• CI パイプラインの状況が把握されている
• 外部依存関係が一覧化されている

---

フェーズ 2：テストピラミッドの提案

目標： フレームワークを選択し、ピラミッドの比率を定義します。

フレームワーク選択表

スタック	単体テスト	結合テスト	E2E
Node.js/TS	Vitest	Vitest + Supertest	Playwright
React/Next.js	Vitest + Testing Library	Vitest + MSW	Playwright/Cypress
Python	pytest	pytest + httpx	Playwright
Go	testing + testify	testing + testcontainers	Playwright
Rust	cargo test	cargo test + testcontainers	-
PHP/Laravel	Pest/PHPUnit	Pest + HTTP tests	Playwright/Dusk

テストピラミッドの比率

        /\
       /  \     E2E Tests (10%)
      /    \    Critical user journeys only
     /------\
    /        \   Integration Tests (30%)
   /          \  API endpoints, DB queries, service interactions
  /------------\
 /              \ Unit Tests (60%)
/                \ Pure functions, business logic, utilities

各レベルでテストする内容

レベル	テスト対象	テストしない対象
単体（60%）	純粋関数、ビジネスロジック、データ変換、バリデーション、状態管理	フレームワークの内部処理、サードパーティライブラリ
結合（30%）	API エンドポイント、データベースクエリ、サービス間呼び出し、認証フロー	個々の関数を単独で実行した場合
E2E（10%）	重要なユーザージャーニー（登録、購入）、クロスブラウザー、アクセシビリティ	エッジケース（単体テストのレベルで対応）

停止 — 次の条件を満たすまでフェーズ 3 に進まないでください：

• フレームワークの選択が技術スタックに合っている
• ピラミッドの比率が定義されている
• 各レベルのテスト範囲が文書化されている

---

フェーズ 3：カバレッジのしきい値を定義

目標： 現実的で、適用可能なカバレッジ目標を設定します。

カバレッジしきい値の表

カテゴリ	最低値	目標値	備考
全体	70%	85%	カバーされた行
重要なパス	90%	95%	認証、決済、データアクセス
新規コード（PR）	80%	90%	CI で適用
ユーティリティ	95%	100%	純粋関数はテストが容易です

しきい値の選択表

プロジェクトの成熟度	全体の最低値	新規コードの最低値	根拠
グリーンフィールド	80%	90%	高い水準から開始し、標準を維持します
開発中（カバレッジ良好）	70%	85%	維持し、改善します
レガシー（カバレッジ低）	50%	80%	下限を段階的に引き上げます
プロトタイプ/MVP	60%	70%	重要なパスをカバーし、未対応箇所を許容します

停止 — 次の条件を満たすまでフェーズ 4 に進まないでください：

• カバレッジのしきい値がプロジェクトの成熟度に対して現実的である
• 重要なパスのカバレッジ目標が定義されている
• CI での適用方針が決定されている

---

フェーズ 4：設定の生成

目標： 動作するテスト設定ファイルと CI 連携を作成します。

作業

1. テストランナーの設定を生成します（vitest.config.ts、jest.config.js、pytest.ini）
2. しきい値を設定してカバレッジを構成します
3. CI ワークフローにテストコマンドを追加します
4. テスト環境（.env.test、テスト用データベース）を設定します

例：Vitest の設定

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    globals: true,
    environment: 'jsdom',
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html'],
      thresholds: {
        lines: 80,
        functions: 80,
        branches: 80,
        statements: 80,
      },
    },
    include: ['src/**/*.test.{ts,tsx}'],
  },
});

停止 — 以下を満たすまでフェーズ 5 に進まないでください：

• 設定ファイルの構文が有効である
• カバレッジのしきい値がフェーズ 3 の決定と一致している
• CI 統合コマンドが定義されている

---

フェーズ 5：テストテンプレートの作成

目標： プロジェクトの規約を示すテストファイルの例を用意します。

作業

1. Arrange-Act-Assert を使った単体テストの例を作成する
2. セットアップ／ティアダウンを含む統合テストを作成する
3. 外部依存関係に対するモック／スタブのパターンを作成する
4. テストデータファクトリー／フィクスチャを作成する
5. （適切な場合）スナップショットテストの例を作成する

停止 — 完了を宣言する前の検証ゲート：

• フレームワークの選択が技術スタックに合っている
• カバレッジのしきい値が現実的である
• テスト設定ファイルが有効である
• テストの例が実際に実行できる
• CI 統合が設定されている

---

アンチパターン／よくある間違い

アンチパターン	問題点	正しいアプローチ
実装の詳細をテストする	リファクタリングのたびに壊れ、誤った安心感を与える	動作と結果をテストする
過剰なモック	実際の動作を何もテストせず、モックが実際の失敗を覆い隠す	境界でのみモックを使う
E2E で壊れやすい CSS セレクターを使う	スタイルの変更で壊れる	data-testid またはアクセシブルなロールを使う
テスト間の依存関係	実行順序による失敗や、CI での不安定さにつながる	各テストを独立して実行できるようにする
遅いテストで CI がブロックされる	開発者がテストの実行を避ける	並列化し、テスト用データベースを使い、外部 API をモックする
スナップショットの多用	読まずにスナップショットが承認され、ベースラインが古くなる	出力が安定している場合にのみ使う
CI でカバレッジを適用しない	時間とともにカバレッジが低下する	CI パイプラインでしきい値を適用する
どこでも同じカバレッジ目標にする	ユーティリティと重要な処理経路では要件が異なる	カテゴリごとにしきい値を設定する

---

決定表：モック戦略

依存関係の種類	モック戦略	例
外部 API	MSW / nock / レスポンス	サードパーティの決済 API
データベース	テスト用データベースまたはインメモリ	PostgreSQL のテストコンテナー
ファイルシステム	仮想ファイルシステムまたは一時ディレクトリ	ファイルアップロード処理
時刻／日付	フェイクタイマー	有効期限のロジック
環境変数	テストセットアップで上書きする	フィーチャーフラグ
乱数／UUID	シード値を設定するか、スタブを使う	ID の生成

---

統合ポイント

スキル	関係
test-driven-development	戦略でフレームワークを定義し、TDD でサイクルを定義する
acceptance-testing	戦略に受け入れテストのインフラストラクチャを含める
code-review	レビューでテストが定義済みの戦略に従っているか確認する
senior-frontend	フロントエンドテストでは、戦略で選択したフレームワークを使う
senior-backend	バックエンドテストでは、戦略で選択したフレームワークを使う
performance-optimization	負荷テストはテスト戦略全体の一部である
webapp-testing	Playwright の E2E テストは戦略ピラミッドに従う

---

主な原則

• 実装ではなく動作をテストする — どのように動くかではなく、何をするか
• 迅速なフィードバック — 単体テストは数秒で実行できるようにする
• 決定論的であること — 不安定なテストや、時刻に依存するロジックをなくす
• 読みやすいこと — テストはドキュメントです。明確に記述してください
• 保守しやすいこと — テストはリファクタリングを助けるものであり、妨げるものであってはなりません

---

スキルの種類

FLEXIBLE — フレームワークの選択とカバレッジのしきい値をプロジェクトの状況に合わせて調整してください。5 フェーズのプロセスとテストピラミッドの構造を強く推奨しますが、プロジェクトの規模に応じて調整できます。