動作する綺麗なコードがTDDのゴール。
TDDでは以下のシンプルなルールしかない。
- 自動化されたテストが失敗した時のみ、新しいコードを書く。
- 重複を除去する
2つのルールは、以下の作業の順序を導く
- レッド: 失敗するテストを一つ書く
- グリーン: 1のテストを迅速に動作させる。このステップでは罪を犯してもいい。
- リファクタリング: テストを通すために発生した重複を全て除去する
レッド、グリーン、リファクタリング。それがTDDのマントラである。
テスト駆動のリズム
作業はテスト駆動のリズムに従う。
- まずはテストを一つ書く。
- 全てのテストを走らせ、新しいテストの失敗を確認する
- 小さな変更を行う
- 全てのテストを走らせて、全て成功することを確認する
- リファクタリングを行なって重複を除去する。
実装を進める上で重要なのは、仮実装モードと明白な実装を使い分けること。
- 仮実装とは: まずベタがきの値を使い、実装を進めるに従って、徐々に変数に置き換えていく。
- 明白な実装: すぐに頭の中の実装をコードに落とす。
仮実装の場合のTDDフローは以下になる。
-
まずはテストを一つ書く
-
全てのテストを走らせ、新しいテストの失敗を確認する
-
最も単純な方法（通常はハードコーディング）でテストを通す
-
全てのテストを走らせて、全て成功することを確認する
-
リファクタリングを行い、徐々に仮実装を本物のコードに置き換える
-
重複を除去する
明白な実装の場合は以下。
- まずはテストを一つ書く
- 全てのテストを走らせ、新しいテストの失敗を確認する
- 実装が明白な場合は、直接「本物の」解決策を実装する
- 全てのテストを走らせて、全て成功することを確認する
- 必要に応じてリファクタリングを行う
三角測量の場合は以下になる。
- まずはテストを一つ書く
- 全てのテストを走らせ、新しいテストの失敗を確認する
- 最も単純な方法でテストを通す
- 別の具体例を示す2つ目のテストを追加する
- 両方のテストを通すために、より一般的な実装に変更する
- 全てのテストを走らせて、全て成功することを確認する
- リファクタリングを行って重複を除去する
これらの使い分けのガイドラインは、以下になる。
- 問題が複雑で解決策が不明確な場合は仮実装 を使用
- 解決策が明白で自信がある場合は 明白な実装 を使用
- より厳密な一般化が必要な場合は 三角測量 を使用