TDDガイド
概要
TDDで機能追加や不具合修正を進めるための、短い反復手順と判断基準を示す。原則として「失敗の確認」を必須とする。
基本ワークフロー
- •仕様を最小の振る舞いに分解する。
- •Red: 失敗するテストを書く。
- •Red確認: 意図した理由で失敗するのを確認する。
- •Green: 最小実装でテストを通す。
- •Green確認: 全テストが通ることを確認する。
- •Refactor: テスト維持のまま設計を改善する。
- •1つの振る舞いごとにサイクルを繰り返す。
鉄則
- •失敗テストなしで本番コードを書かない。
- •失敗を見ていないテストは無効とみなす。
- •例外が必要なら人に相談する。
テスト設計の指針
- •仕様を例で表現する。
- •失敗理由が1つになるようにする。
- •I/O境界と純粋ロジックを分ける。
- •テスト名は「条件_期待結果」など意図が分かる形にする。
Greenの指針
- •最小のコードで通す。
- •早すぎる抽象化を避ける。
- •まずはハードコードで通してもよい。
Refactorの指針
- •重複を削減し、命名と責務を整える。
- •既存テストが通ることを維持する。
- •テストが不足している場合は先に追加する。
よくある失敗と対処
- •失敗テストなしで実装する → 実装を削除してRedからやり直す。
- •テストがすぐ通る → 既存挙動の可能性があるためテストを見直す。
- •「簡単だから省略」 → 省略せず最小のテストを1つ書く。
つまずいた時
- •テストが難しい → 仕様や設計を簡素化し、扱いやすいAPIにする。
- •モックだらけ → 依存を切り出し、境界の設計を見直す。
検証チェックリスト
- •新しい振る舞いごとにテストを書いた。
- •Redの失敗を確認した。
- •失敗理由が意図通りだった。
- •Greenで全テストが通った。
- •Refactor後も全テストが緑のまま。
- •テスト出力に警告やエラーがない。
依頼対応の進め方
- •まず振る舞いを確認し、最小のテストケースに落とす。
- •1サイクルずつ進め、各段階の差分を明確に示す。
- •既存テストがある場合は整合性を確認する。