t_wada 式 TDD(テスト駆動開発)
和田卓人氏(@t_wada)が提唱する、Kent Beck の定義に基づく正統な TDD 実践ガイド。
TDD とは何か
TDD は「開発者テストをより効率的に進めるための Tips 集」である。
テストを書くタイミングと実装のタイミングを近づけ、同じ人がテストと実装を担当することで生じる課題を解決する手法
5 ステップサイクル(Kent Beck の定義)
text
1. テストリストを書く ↓ 2. リストから 1 つ選び、テストを書く(Red: 失敗を確認) ↓ 3. テストを通す最小限の実装(Green) ↓ 4. 必要に応じてリファクタリング(Refactor) ↓ 5. テストリストが空になるまで 2 へ戻る
重要: Red-Green-Refactor だけでは不十分。テストリストが核心。
核心原則
1. テストリストを作る
実装前にテストすべきシナリオをリスト化する。
markdown
## テストリスト - [ ] 正の整数を渡すとその値を返す - [ ] 0 を渡すと 0 を返す - [ ] 負の整数を渡すと絶対値を返す - [ ] null を渡すと例外を投げる
2. 一度に 1 つだけ
- •テストリストから 1 つだけ 選ぶ
- •1 つだけ のテストを書く
- •1 つだけ の変更で Green にする
3. 「動く」と「きれい」を分離
text
Red: テストを書く(失敗を確認) Green: テストを通す(動くコード) ← ここでは「動く」だけを追求 Refactor: 設計を改善(きれいなコード) ← ここで「きれい」を追求
同時に追求しないことで認知負荷を下げる。
4. 小さなステップ
- •大きな変更は小さな変更の積み重ね
- •不安なら歩幅を小さく
- •自信があれば歩幅を大きく
実装パターン(Green にする 3 つの戦略)
| パターン | 説明 | 使いどころ |
|---|---|---|
| 仮実装 | ハードコードで Green にする | 最初の一歩、不安時 |
| 三角測量 | 複数テストで一般化を強制 | 一般化の方向が不明時 |
| 明白な実装 | 自明なら直接正しい実装を書く | 自信がある時 |
詳細: references/implementation-patterns.md
TDD サイクル詳細
詳細なサイクルの回し方: references/tdd-cycle.md
テスト記述の Tips
テストの書き方: references/test-writing-tips.md
チェックリスト
各フェーズのチェックリスト: references/checklists.md
TDD のメリット
- •使いやすい設計: テスト先行により使用者視点の設計が実現
- •自己効力感: 小さな成功の積み重ねがモチベーションを生む
- •安心してリファクタリング: テストがセーフティネット
- •ドキュメントとしてのテスト: テストが仕様を表現
TDD ではないもの
- •テストを先に全部書くこと(× テストファースト)
- •設計をスキップすること
- •自動テストを書くこと全般
クイックリファレンス
| フェーズ | やること | やらないこと |
|---|---|---|
| テストリスト | シナリオを網羅的にリスト化 | 完璧を目指す |
| Red | 失敗するテストを 1 つ書く | 複数テストを同時に書く |
| Green | 最小限の実装で通す | きれいなコードを書く |
| Refactor | 重複除去・設計改善 | 新機能を追加する |
参考資料
- •テスト駆動開発(Kent Beck 著、和田卓人 訳)
- •【翻訳】テスト駆動開発の定義
- •TDDは「開発者テストのTips集」