テスト駆動開発は「テスト手法」にあらず

Ryuzee.com の (書評)テスト駆動開発による組み込みプログラミング を見た。

そこから飛んで、著者のインタビュー（前編）と（後編）を読んだ。

実は先日、この本を手にとったのだが、「あんまり使えるものはないかも...」と思い、そのときはスルーしてしまった。

が、このインタビューがちょっと気になる。以下に抜粋しながら引用する（青字）。

驚いたことの一つが、彼らの考え方はその当時主流だった考え方と違っていたことです。90年代に一般的だったのは「正しい開発プロセスがあれば、開発者はもっと上手くやるだろう」というものでした。しかし、アジャイルソフトウェア開発宣言を共に検討したメンバーの意見は「スキルのある優れた開発者がいれば、彼ら自身が学習して開発プロセスを決めれば良い」です。
それとは対象的に、多くの会社ではソフトウェア開発の管理や開発プロセスの改善の話をするとき、会社がやって欲しい通りに仕事をさせようとします。IT産業のやっていることは「うちには取り替え可能なプログラミングユニットの開発者がいる。彼らが開発プロセスに従えば、ソフトウェアの問題はなくなるだろう。」というもの。しかし、アジャイルソフトウェア開発宣言で我々が語っているのは人の重要性です。これは驚くべきものでした。

うんうん、そうだった。

多くの人がTDDのコード中心な側面を見て、「TDDは設計しない手法だ」と誤解しますが、実際に我々がやっているのは継続的な設計です。

テストはオブジェクトがどのように動くかを明確に示してくれます。そしてインタフェースが使いやすいかも示してくれます。これは私が長年の経験の中で得た結論です。

TDD をやれば、他のテスト手法が不要になるということはありません。TDD はコードがプログラマの考えた通りのことをしているか確かめる手法です。そして、コードの問題を早く見つけられるようにし、そこにあったことすら気づいていなかった問題を取り除くための手法です。(...)ただし、TDD のテストはモジュールがプログラマの考えた通りに動いていることは示してくれますが、製品が仕様通りだとは言いません。製品が仕様通りか確認するためのテストは必要になります。

手動テストをゼロにして、全て自動化しろという意味ではありません。我々がやりたいことは、必要な手動テストの量を減らすことです。そして不具合の検出を受け身で待つのではなく、能動的に不具合を防ぐことです。

テストケースを選ぶことで設計を汎用化していく過程を見れば、多くの人はTDDの設計の側面を理解してもらえると思います。テストケースがひと通り終わった時に汎用的な設計が完了しています。

そうだった、そうだった。テストは「設計」なのだ。

そして再度、書店で手にとってみた。とどめは平鍋氏のまえがきだ（以下）。

よく誤解されるのだが、テスト駆動開発は「テスト手法」ではない。ユニットテストをうまく利用して、よりよい設計に導くための手法である。この手法で開発されたソースコードは、「テストしやすい設計」になると同時に、動くユニットテスト群が同時に開発される、という優れものだ。このユニットテスト群は回帰テストで利用されるとともに、将来の設計変更を安全に導く基礎になる。

多分私は、「テストっておもしろくなさそう...」と感じて敬遠していたのだ。
ちゃんと書いてあるじゃないか、サブタイトルにも。「C言語とオブジェクト指向で学ぶアジャイルな設計」ってｗ。

もう一度「TDD とは何か」をよく考えながら読んでみよう、きっと得るものはあるはずだ。
そう思って、今日は買ってきた。連休中にさーっと流してみるか。