TDD.NET

■ TDD を提唱したのは誰か?

Test Driven Development を提唱したのは Kent Beck ということになってます。

※ Google 検索結果 より

2002年の 2月には、「YAHOO! GROUPS」 に TDD のグループが作られています。

ですから、 Kent Beck を含む XP のコミュニティ内部では、 それ以前から使われていた言葉でしょう。 すでに XP のプラクティスに 「テスト ファースト」 と 「リファクタリング」 があって、 実際にはそれらをひと続きの開発作業として行っていましたから、 両方をまとめて呼ぶ名前も必要だったわけです。

そして、 Kent Beck は 2002年の 11月に 「Test-Driven Development: By Example」(邦訳：「テスト駆動開発入門」)を上梓しました。

この本に示された TDD の定義が、 一般に公表された最初のものであり、 そして今に至るまで Kent Beck はその定義を変更していません。

■ TDD とは何か?

ということで、「Test-Driven Development: By Example」 から引用します。

◇ TDD の規則

In Test-Driven Development, we
• Write new code only if an automated test has failed
• Eliminate duplication
These are two simple rules,

(私訳)
テスト駆動開発において我々は、
• 自動テストが失敗している場合に限り、 新しいコードを書く。
• 重複を取り除く。
これらは 2つのシンプルな規則だ。

規則のひとつめは、 テストファーストのことです。 ふたつめは、 リファクタリングのことです。 ( この部分は以前にも紹介しました )

TDD = テストファースト + リファクタリング

このルールを守っていれば TDD していると言えるし、 そうでなければ ( カバレッジ 100% のユニット テストが最終的に完成したとしても ) TDD していません。

また、「自動テスト (automated test)」 と言っていることに注意してください。 手動テストのスペックを先に決めたからテストファースト、 とは言えないのです。

そして、「テスト駆動 『開発』 」 と言っているくせに、 コーディングに関わる規則だけを定めていることにも注意してください。 TDD は開発プロセスではないのです。

◇ TDD の実際

The two rules imply an order to the tasks of programming.
1. Red -- Write a little test that doesn't work, and perhaps doesn't even compile at first.
2. Green -- Make the test work quickly, committing whatever sins necessary in the process.
3. Refactor -- Eliminate all of the duplication created in merely getting the test to work.
Red / green / refactor -- the TDD mantra.

(私訳)
その2つの規則は、 プログラミングのタスクに対するオーダー (命令) を意味します。
1. レッド -- 動かない (たぶん最初はコンパイルすらできない) テストを少し書く。
2. グリーン -- テストを速やかに動くようにする。その過程で必要ならどんな罪をも犯す。
3. リファクタリング -- テストを動くようにするために作られたにすぎない重複をすべて除去する。
レッド / グリーン / リファクタリング -- TDD の呪文

■ TDD の何が難しいのか?

TDD 自体では、 おそらくテストファーストが難しいでしょう。
これから作るパーツのスペック (OOP 風に言うなら、「これから作るオブジェクトに与えるメッセージと、そのメッセージに対する (オブジェクトの外的な) 振る舞い」) を自分で決定してからコーディングに取り掛かる、 という習慣を持っていない開発者は途方に暮れるかもしれません。

また、 テストファーストもリファクタリングも、 どのようなアーキテクチャが良いか、 どんなデザインパターンが適用できるかといった 「基礎知識」 を必要とします。 その他、 コーディングに必要な知識は何でも必要とします。 TDD はプログラムを作るときのプラクティスですから、 当たり前と言えば当たり前ですけどね。

それでも、 楽に TDD できる範囲を、 開発プロジェクトの最初から TDD していくのは、 まだそれほど困難なことではありません。 TDD しにくい (=コスト パフォーマンスが悪い) ところ、 たとえば UI も TDD しようとするのは大変です (コスト パフォーマンスが見合わないので、 実際の開発ではまずやりません)。

そして、 もっとも困難なのは、 TDD してこなかったレガシー コードを、 TDD で機能の追加・変更できるようにするために改修する作業でしょう。 それは、 既存コードをメンテナンスし続けなければならない開発チームが TDD するために必要な準備作業ですが、 しかし TDD ではありません。

最後は、 TDD よりも、 TDD できるように既存コードを改修する方が難しい、 という話でした。