tdd

コミュニティのテスト駆動開発のベストプラクティス

AI エージェントと LLM 向けに設計された、テスト駆動開発の実践に関する包括的なガイドです。8 つのカテゴリにわたる 42 のルールを、テストの作成、リファクタリング、コード生成を導く影響度順にまとめています。

適用する場面

次のような場合に、これらのガイドラインを参照してください。

• TDD ワークフローを使って新しいテストを作成する
• レッド・グリーン・リファクタリングのサイクルを実施する
• テストの構成や整理方法を設計する
• テストデータやフィクスチャを作成する
• 既存のテストスイートをレビューまたはリファクタリングする

TDD ワークフロー

1. RED：望ましい動作を定義する、失敗するテストを書く
2. GREEN：テストに合格するために必要最小限のコードを書く
3. REFACTOR：テストをグリーンのまま保ち、コードを整理する
4. 新しい動作ごとに繰り返す

優先度別のルールカテゴリ

優先度	カテゴリ	影響度	プレフィックス
1	レッド・グリーン・リファクタリングのサイクル	重大	cycle-
2	テスト設計の原則	重大	design-
3	テストの分離と依存関係	高	isolate-
4	テストデータ管理	高	data-
5	アサーションと検証	中	assert-
6	テストの整理と構成	中	org-
7	テストのパフォーマンスと信頼性	中	perf-
8	テストピラミッドと戦略	低	strat-

クイックリファレンス

1. レッド・グリーン・リファクタリングのサイクル（重大）

• cycle-write-test-first - 実装の前にテストを書く
• cycle-minimal-code-to-pass - テストに合格するために必要なコードだけを書く
• cycle-refactor-after-green - グリーンになったらすぐにリファクタリングする
• cycle-verify-test-fails-first - コードを書く前にテストが失敗することを確認する
• cycle-small-increments - 小さなステップで段階的に進める
• cycle-maintain-test-list - テストのリストを管理する

2. テスト設計の原則（重大）

• design-test-behavior-not-implementation - 実装ではなく動作をテストする
• design-one-assertion-per-test - 1 つのテストにつき 1 つの論理的なアサーションを行う
• design-descriptive-test-names - 内容がわかるテスト名を付ける
• design-aaa-pattern - 準備・実行・検証のパターンに従う
• design-test-edge-cases - エッジケースと境界値をテストする
• design-avoid-logic-in-tests - テスト内のロジックを避ける

3. テストの分離と依存関係（高）

• isolate-mock-external-dependencies - 外部依存関係をモックする
• isolate-no-shared-state - テスト間で変更可能な状態を共有しない
• isolate-deterministic-tests - 決定的なテストを書く
• isolate-prefer-stubs-over-mocks - クエリにはモックよりスタブを優先する
• isolate-use-dependency-injection - テスト容易性のために依存性注入を使う

4. テストデータ管理（高）

• data-use-factories - テストデータの作成にファクトリーを使う
• data-minimal-setup - テストのセットアップを最小限にする
• data-avoid-mystery-guests - 正体がわかりにくいテストデータを避ける
• data-unique-identifiers - テストごとに一意の識別子を使う
• data-builder-pattern - 複雑なオブジェクトにはビルダーパターンを使う

5. アサーションと検証（中）

• assert-specific-assertions - 具体的なアサーションを使う
• assert-error-messages - エラーメッセージと型をアサートする
• assert-no-assertions-antipattern - すべてのテストにアサーションを含める
• assert-custom-matchers - ドメイン固有のアサーションにはカスタムマッチャーを作成する
• assert-snapshot-testing - スナップショットテストは慎重に使う

6. テストの整理と構成（中）

• org-group-by-behavior - メソッドではなく動作ごとにテストをまとめる
• org-file-structure - テストファイルの構成を一貫させる
• org-setup-teardown - セットアップと後処理のフックを適切に使う
• org-test-utilities - 再利用可能なテストユーティリティを切り出す
• org-parameterized-tests - 条件の違いにはパラメーター化テストを使う

7. テストのパフォーマンスと信頼性（中）

• perf-fast-unit-tests - 継続的なフィードバックを得られるよう、ユニットテストを十分に高速に保つ
• perf-avoid-network-calls - ユニットテストでのネットワーク呼び出しをなくす
• perf-fix-flaky-tests - 不安定なテストはすぐに修正する
• perf-parallelize-tests - 独立したテストを並列実行する
• perf-avoid-sleep - 任意のスリープ呼び出しを避ける

8. テストピラミッドと戦略（低）

• strat-test-pyramid - テストピラミッドに従う
• strat-mutation-testing - ミューテーションテストを使用してテストの品質を検証する
• strat-coverage-targets - 意味のあるカバレッジ目標を設定する
• strat-integration-boundaries - サービス境界で統合テストを行う
• strat-e2e-critical-paths - E2E テストを重要なユーザーパスに限定する

使用方法

上記のルールのうち、タスクに該当するものについて、references/<rule-id>.md を読み、重要な理由と、誤ったコードと正しいコードを確認してください。

関連スキル

• Vitest フレームワークの詳細については、vitest スキルを参照してください
• MSW を使用した API のモックについては、msw スキルを参照してください