tdd

TDD

このスキルは、単独で作業するワークフローとして使用してください。ワーカー、タスクの割り当て、チームでの調整といった概念は導入しないでください。

基本ルール

• 実装する前に、依頼内容、関連するコード、制約を確認します。
• 本番コードを書く前に、完了の条件を定義します。
• タスクで自動テストを利用できる場合は、レッドフェーズを優先します。
• E2E をデフォルトにしないでください。明示的に求められている場合、タスクの契約ですでに必須となっている場合、または低コストの検証では受け入れリスクをカバーできない場合に限り、E2E を使用します。
• テストケースの設計、回帰テストの計画、受け入れ範囲の確認、または広範な QA の実施が必要な場合は、このスキルを完全な QA ワークフローに拡張せず、qa-expert を呼び出します。
• 自動テストが適切でない場合は、実装前に手動検証の手順を定義します。
• 検証が完了するまで、作業を完了したとみなさないでください。
• 検証を省略する場合は、その理由と残るリスクを明示します。

ワークフロー

次の順序に従います。

1. コンテキストを確認する
2. 受け入れ基準を定義する
3. 可能であれば失敗するテストを書く
4. 実装する
5. 検証する
6. 結論を出す

前のステップが明確に満たされていない限り、先に進まないでください。

ステップ 1：コンテキストを確認する

変更を加える前に、依頼内容と周辺の実装を調査します。

次の点を確認します。

• 目標
• 対象範囲
• 制約
• 対象外の事項
• 既存の検証方法

依頼内容が曖昧な場合は、作業を止め、続行する前に曖昧さを解消してください。

ステップ 2：受け入れ基準を定義する

実装前に受け入れ基準を記述します。

次の点を含めます。

• 期待される動作
• エッジケース
• 失敗ケース
• 完了を確認できる条件

受け入れ基準をまだ記述できない場合、そのタスクは実装に着手できる状態ではありません。

ステップ 3：可能であれば失敗するテストを書く

自動検証を利用できる場合は、実装前にテストを作成または更新します。

実際にレッドフェーズとなるようにします。

• 新しい動作をアサートする
• 現在のコードがそのアサーションに失敗する
• 期待される結果が明確である

自動テストが適切でない場合は、次に進む前に手動検証の手順を明確に定義します。

ステップ 4：実装する

受け入れ基準と検証計画に沿って実装します。

受け入れ基準を先に更新しない限り、実装中に対象範囲を広げないでください。

ステップ 5：検証する

利用可能な範囲で、次の順に最も確実な検証方法を使用します。

1. 既存の自動テスト
2. 変更のために追加した自動テスト
3. 具体的な手順と期待される結果を定めた、再現可能な手動検証
4. 現在の環境で検証が妨げられている場合に限り、skipped

E2E をデフォルトの検証方法にしないでください。E2E が明示的に必須である場合、または受け入れリスクをほかの方法でカバーできない場合を除き、まず低コストの確認を優先します。

検証中に専用のテストケース設計、回帰テストの実施、または広範な QA 対応が必要な場合は、qa-expert を呼び出します。

検証に失敗した場合は、結論を出す前に実装に戻り、問題を修正します。

ステップ 6：結論を出す

次のいずれか1つを、必ず結果として記載します。

• passed
• failed
• skipped

結論には、次の内容を含めます。

• 変更内容の簡潔な概要
• 使用した検証方法
• 結果
• 残るリスク（ある場合）

結果が skipped の場合は、その理由と、検証しなかったことで生じる具体的なリスクを記載します。

失敗条件

次のいずれかに該当する場合は、実装前に作業を止めて問題を解消します。

• 要件が不明確である
• 受け入れ基準がない
• 検証方法が定義されていない

次の場合は作業に戻り、解決するまで続けます。

• テストが予期せず失敗する
• 検証コマンドが失敗する
• 手動検証で受け入れ基準を満たせない

任意の成果物

役立つ場合に限り、軽量な成果物を使用します。

• proposal.md
• design.md
• tests.md
• 明示的な検証コマンド

周辺のプロジェクトですでに採用されている場合を除き、固定のディレクトリ構成を必須にしないでください。