TDD.NET

また、 先月のこと、 新人研修にて。 メソッドの外部設計は、 テストコードとして記述できるよね、 といった内容を喋ったところ、 「メソッドの外部設計はいつやるのですか? テストのときですか?」 という質問をされました。 ( 正解は、 外部設計は内部設計の前に始める、 です。 )

「テストファースト」 という名前に 「騙されて」 いる面もあるかとは思います。

もうひとつ。 「テストケースはテストのときに作る」 という悪癖に影響されている部分も大きいのではないかと思います。

プログラムを稼動させて行うテストの目的は、 外部設計の通りにプログラムが動くことを証明すること、 です。 ( 機能だけでなく、 性能やセキュリティの要件も外部設計に含まれます。 )
テストケースというのは、 外部設計の具体例です。  たとえば、 「入力した 2数の和を出力する」 という外部設計の具体例は、 「1 と 2 を入力したら 3 が出力される」 といったものになりますね。
外部設計の具体例 (テストケース) は、 外部設計に含まれているべきではありませんか?

機械の設計だったら当たり前のこと ( というよりも、 テスト方法と数値が示されなければ、 設計のやりようがない ) なのですが、 ソフトウェアではテストケースの作成はなぜか後回しにされてしまいます。 そして、 実装が終わってからテストケースが作成され… ようやくテストが始まると、 開発者は 「そんな話、 聞いてないよ～っ!!」 と叫ぶことになります。 この悲劇は、 本来先に作っておいて、 開発者に対してゴールとして提示すべきテストケースを、 後回しにしたから起きるのです。 ゴールが分からないままにプログラムを作る開発者は、 外部設計書を自分なりに解釈し、 そして道に迷い、 ゴールをクリアするためには必要の無いコードまで書き、 そのあげく、 後出しのテストケースと違うからバグがあると言われます。 あきらかに、 開発者にムダな時間を使わせています。 
今現在、 多くの現場では、
実装 → テストケース作成 → テスト実施
という手順で進めているでしょうけれど、 トータルの作業効率を考えるならば、
テストケース作成 → 実装 → テスト実施
という順序で行うべきなのです。 これは、 メソッドレベルの単体テストでも同じことです。

さて。
テストケースは本来先に作るべき、 とすると、 単体テストの正しい従来の手順はこうです。
・ テストケース作成 → 実装 → テスト実施

テストファーストでは、 こうです。
・ ユニットテスト作成(レッド) → 実装 → ユニットテスト実施(グリーン)

同じ順序で作業していますね。
異なる点は、 従来ならば、 まとめてテストケースを作り、 それから全部を実装し、 最後にテストをすべて実施するところを、 テストファーストでは、 テストケース単位くらいに細かく分けて 3つを繰り返すところです。

もういちど。
テストファーストは、 「ユニットテストを先に用意する」 という意味であって、 「テストを先に実施する」 という意味ではありません。