tdd-workflows-tdd-cycle

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

• TDD ワークフロー、TDD サイクルのタスク、またはワークフローに取り組む場合
• TDD ワークフロー、TDD サイクルに関するガイダンス、ベストプラクティス、チェックリストが必要な場合

このスキルを使用しない場面

• タスクが TDD ワークフロー、TDD サイクルに関係しない場合
• この範囲外の別の分野やツールが必要な場合

手順

• 目標、制約、必要な入力を明確にします。
• 関連するベストプラクティスを適用し、成果を検証します。
• 実行可能な手順と検証方法を提示します。
• resources/implementation-playbook.md は同梱されていません。内容を作り上げず、この依存ファイルが利用できないことを報告してください。

厳格なレッド・グリーン・リファクタリングの規律に従い、包括的なテスト駆動開発（TDD）ワークフローを実行します。

[拡張思考：このワークフローでは、連携したエージェントのオーケストレーションを通じて、テストファースト開発を徹底します。TDD サイクルの各フェーズを厳格に適用し、必ず失敗を先に確認してから、段階的に実装し、継続的にリファクタリングします。ワークフローは、設定可能なカバレッジのしきい値を使った、単一テストとテストスイートの両方のアプローチに対応しています。]

ホスト環境とエビデンスの範囲

以下に示す Task／サブエージェントの種類は連携の例であり、利用可能なツールとしてインストールされているとは限りません。ユーザーやリポジトリの制約に従い、ホスト環境でサポートされているワークフローを使用してください。カバレッジと複雑度のしきい値は初期評価基準であり、普遍的に正しい基準ではありません。RED フェーズで既存のテストが失敗する必要はありません。既存のテストを成功状態に保ちながら、新しく追加した各テストが、意図した動作の未実装を理由に失敗することを確認してください。TDD のフェーズを整えるために、無関係な変更やユーザーによる変更を決してロールバックしないでください。

設定

カバレッジのしきい値

• 最小行カバレッジ：80%
• 最小分岐カバレッジ：75%
• クリティカルパスのカバレッジ：100%

リファクタリングのトリガー

• 循環的複雑度 > 10
• メソッドの長さ > 20 行
• クラスの長さ > 200 行
• 重複するコードブロック > 3 行

フェーズ 1：テスト仕様と設計

1. 要件分析

• subagent_type="comprehensive-review::architect-review" を指定して Task ツールを使用します
• プロンプト："次の要件を分析してください：$ARGUMENTS。受け入れ基準を定義し、エッジケースを特定して、テストシナリオを作成してください。包括的なテスト仕様を出力してください。"
• 出力：テスト仕様、受け入れ基準、エッジケースのマトリクス
• 検証：すべての要件に対応するテストシナリオがあることを確認します

2. テストアーキテクチャの設計

• subagent_type="unit-testing::test-automator" を指定して Task ツールを使用します
• プロンプト："テスト仕様に基づき、次の要件のテストアーキテクチャを設計してください：$ARGUMENTS。テスト構造、フィクスチャ、モック、テストデータの方針を定義してください。テスト容易性と保守性を確保してください。"
• 出力：テストアーキテクチャ、フィクスチャの設計、モック方針
• 検証：分離された、高速で信頼性の高いテストをサポートするアーキテクチャであることを確認します

フェーズ 2：RED — 失敗するテストを書く

3. 単体テストを書く（失敗する状態）

• subagent_type="unit-testing::test-automator" を指定して Task ツールを使用します
• プロンプト："次の要件について、失敗する単体テストを書いてください：$ARGUMENTS。テストは最初に失敗する必要があります。エッジケース、エラーケース、正常系を含めてください。本番コードは実装しないでください。"
• 出力：失敗する単体テスト、テストのドキュメント
• 重要：すべてのテストが想定どおりのエラーメッセージで失敗することを確認します

4. テストの失敗を確認する

• subagent_type="tdd-workflows::code-reviewer" を指定して Task ツールを使用します
• プロンプト："次の要件に関するすべてのテストが正しく失敗していることを確認してください：$ARGUMENTS。失敗の理由が正しいこと（テストのエラーではなく、実装がないこと）を確認してください。誤検知がないことを確認してください。"
• 出力：テスト失敗の確認レポート
• ゲート：すべてのテストが適切に失敗するまで、次に進まないでください

フェーズ 3：GREEN — テストを成功させる

5. 最小限の実装

• subagent_type="backend-development::backend-architect" を指定して Task ツールを使用します
• プロンプト："次の要件について、テストを成功させるために必要な最小限のコードを実装してください：$ARGUMENTS。テストを成功させることだけに集中してください。追加機能や最適化は加えないでください。シンプルに保ってください。"
• 出力：動作する最小限の実装
• 制約：テストを成功させるために必要な範囲を超えるコードを追加しないでください

6. テストの成功を確認する

• subagent_type="unit-testing::test-automator" を指定して Task ツールを使用します
• プロンプト：「$ARGUMENTS のすべてのテストを実行し、合格することを確認してください。テストカバレッジの指標を確認してください。テストが誤って壊されていないことを確認してください。」
• 出力：テスト実行レポート、カバレッジ指標
• ゲート：次に進む前に、すべてのテストに合格する必要があります

フェーズ 4：リファクタリング ― コード品質を向上させる

7. コードのリファクタリング

• subagent_type="tdd-workflows::code-reviewer" を指定して Task ツールを使用します
• プロンプト：「テストを成功状態に保ちながら、$ARGUMENTS の実装をリファクタリングしてください。SOLID 原則を適用し、重複を排除し、命名を改善し、パフォーマンスを最適化してください。リファクタリングのたびにテストを実行してください。」
• 出力：リファクタリング済みコード、リファクタリングレポート
• 制約：テストは常に成功状態を維持する必要があります

8. テストのリファクタリング

• subagent_type="unit-testing::test-automator" を指定して Task ツールを使用します
• プロンプト：「$ARGUMENTS のテストをリファクタリングしてください。テストの重複を削除し、テスト名を改善し、共通のフィクスチャを抽出し、テストの読みやすさを高めてください。テストで同じカバレッジが確保されることを確認してください。」
• 出力：リファクタリング済みテスト、改善されたテスト構成
• 検証：カバレッジ指標が同等または向上していること

フェーズ 5：統合テストとシステムテスト

9. 統合テストを書く（まず失敗させる）

• subagent_type="unit-testing::test-automator" を指定して Task ツールを使用します
• プロンプト：「$ARGUMENTS の失敗する統合テストを書いてください。コンポーネント間の連携、API 契約、データフローをテストしてください。テストは最初に失敗する必要があります。」
• 出力：失敗する統合テスト
• 検証：統合ロジックが不足しているため、テストが失敗すること

10. 統合を実装する

• subagent_type="backend-development::backend-architect" を指定して Task ツールを使用します
• プロンプト：「統合テストに合格するよう、$ARGUMENTS の統合コードを実装してください。コンポーネント間の連携とデータフローに重点を置いてください。」
• 出力：統合の実装
• 検証：すべての統合テストに合格すること

フェーズ 6：継続的な改善サイクル

11. パフォーマンスとエッジケースのテスト

• subagent_type="unit-testing::test-automator" を指定して Task ツールを使用します
• プロンプト：「$ARGUMENTS のパフォーマンステストと追加のエッジケーステストを追加してください。ストレステスト、境界値テスト、エラー復旧テストを含めてください。」
• 出力：拡張されたテストスイート
• 指標：テストカバレッジとシナリオカバレッジの向上

12. 最終コードレビュー

• subagent_type="comprehensive-review::architect-review" を指定して Task ツールを使用します
• プロンプト：「$ARGUMENTS を包括的にレビューしてください。TDD プロセスが遵守されていることを確認し、コード品質、テスト品質、カバレッジを確認してください。改善案を提案してください。」
• 出力：レビューレポート、改善案
• 対応：テストを成功状態に保ちながら、重要な提案を実装します

インクリメンタル開発モード

テスト単位で開発する場合：

1. 失敗するテストを 1 つ書く
2. そのテストだけを成功させる
3. 必要に応じてリファクタリングする
4. 次のテストに進み、繰り返す

通常の言葉でインクリメンタルモードを指定してください。実行可能な CLI や --incremental パーサーは同梱されていません。

テストスイートモード

包括的なテストスイートを開発する場合：

1. 機能／モジュールのテストをすべて書く（失敗する状態）
2. すべてのテストに合格するコードを実装する
3. モジュール全体をリファクタリングする
4. 統合テストを追加する

通常の言葉でスイートモードを指定してください。実行可能な CLI や --suite パーサーは同梱されていません。

検証チェックポイント

RED フェーズの検証

• 実装前にすべてのテストが書かれている
• すべてのテストが、意味のあるエラーメッセージとともに失敗する
• テストの失敗原因が実装の不足である
• テストが誤って合格していない

GREEN フェーズの検証

• すべてのテストに合格する
• テスト要件を超えるコードがない
• カバレッジが最低しきい値を満たしている
• テストを合格させるために変更していない

リファクタリングフェーズの検証

• リファクタリング後もすべてのテストに合格する
• コードの複雑さが軽減されている
• 重複が排除されている
• パフォーマンスが向上または維持されている
• テストの読みやすさが向上している

カバレッジレポート

各フェーズの後にカバレッジレポートを生成します：

• 行カバレッジ
• 分岐カバレッジ
• 関数カバレッジ
• ステートメントカバレッジ

障害からの復旧

TDD の規律が破られた場合：

1. ただちに停止します
2. どのフェーズに違反したかを特定します
3. 最後の有効な状態にロールバックします
4. 正しいフェーズから再開します
5. 得られた教訓を記録します

TDD メトリクスの追跡

次の項目を追跡して報告します：

• 各フェーズ（Red／Green／Refactor）にかかった時間
• テストと実装のサイクル数
• カバレッジの推移
• リファクタリングの頻度
• 欠陥の流出率

避けるべきアンチパターン

• テストより先に実装を書く
• すでに成功するテストを書く
• リファクタリングのフェーズを省略する
• テストを書かずに複数の機能を実装する
• テストを変更して成功させる
• 失敗しているテストを無視する
• 実装後にテストを書く

成功基準

• コードの 100％をテストファーストで記述する
• すべてのテストが継続的に成功する
• カバレッジがしきい値を超える
• コードの複雑さが制限内に収まる
• 観察された欠陥や不足を報告する。カバレッジやテストの成功は、欠陥がゼロであることの証明にはなりません
• テストのドキュメントが明確である
• テストの実行が速い（単体テストは 5 秒未満）

注意事項

• RED-GREEN-REFACTOR の規律を厳守します
• 次のフェーズに進む前に、各フェーズを完了させます
• テストが仕様です
• テストを書くのが難しい場合は、設計の改善が必要です
• リファクタリングは任意ではありません
• テストの実行を速く保ちます
• テストは相互に独立し、分離されている必要があります

TDD の実装対象：$ARGUMENTS

例

ユーザーのリクエスト：

red-green-refactor サイクルでこの動作を実装し、失敗するテスト、最小限の修正、最終的に成功するチェックを示してください。

制限事項

• このスキルは、タスクが上記の説明された範囲に明確に該当する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、停止して確認を求めてください。