TDDはテスト手法ではない

test

僕が2004/02/08に書いたエントリを再掲します。当時書いたときからあまり感覚は変わっていないです。

2004/02/08@旧TECHMemoより
http://66.102.7.104/search?q=cache:HPeO-cgo84MJ:dann.dyndns.info/diary/20040208.html+dann.dyndns.info+TDD&hl=ja&lr=lang_ja&client=firefox-a

TDDはテスト手法ではない

TDDは設計手法です。

Jon Trisenさんは、TDD is about Testingだと言っていますが、自分はそうは思いません。TDD isn't about Testingです。極論すれば、TDD is about Desingingです。Kent BeckもTDD本の中でそれを伝えようとしています。

設計をするために、ユニットテストを書くのであって、テストをするためにUnitTestを書くわけではありません。TDDでは最初に動作を補償するために多くのテストケースを書く必要はありません。

設計を行う段階では試行錯誤を繰り返すわけで、その段階で多くの「テスト」書いてはいけないのです。間違っていると気づいたときに、テストコードと実装コードの両方の面倒を見ることになってしまいます。

ユニットレベルで設計を行うことができてから、リファクタリングを行うために必要な、ある程度のユニットテストを書けばいいと思っています。

設計をするためのユニットテスト、リファクタリングを行うためのユニットテスト、テストとしてのユニットテストは意味合いが違うのです。

多くの雑誌では、TDDでのユニットテストは、テストとしてのユニットテストの意味合いで書いていますが、そうではないのです。TDDでは、Drive Design on unit levelするために、testabilityの高い設計になるため、柔軟な設計ができるわけです。ここがTDDのキーポイントです。

TDDを勘違いをしている人の多くは、TDDを始めてもテストケースはあるが柔軟な設計にならない、もしくは、テストケースのために実装コードを変更できないということになると思います。

＃TDDについてはRobert C. Martinの本を読むと、TDDの意味合いがよくわかると思います