TDDのテストと一般的なテストは別物

TDDを実践する目的､それは｢動作するきれいなコード｣を書くことである｡
ちょっと抽象的な表現かもしれませんが､私はこう解釈します｡

仕様どおり動作する保守性の高いコード

これが最終的に成果物として出力されることになります｡
つまりTDDのテストとは､仕様どおり動作する保守性の高いコードを書くための作業と言い換えることができます｡

一方､一般的にテストといえば､バグの洗い出しやパフォーマンス検証を目的としています｡
これは､想定外の動作をしないことを証明するための作業と言い換えることができます｡

上記の事から

一般的なテストはプログラミングの結果に対してのみ作用するもの
TDDのテストはプログラミングの過程に対しても作用するもの

であると解釈できます｡

TDDは､プログラミングの過程すべてに作用します｡
とりわけ設計に関しては､最も直接的かつ効果的に作用する部分だと思います｡

テストを書くということは設計するということ

TDDにおけるテストとは､ふるまいを定義するということです｡
例えばFizzBuzzの振る舞いを書くと以下のようになります｡

数を文字列として返す
数が3の倍数の場合は｢Fizz｣を返す
数が5の倍数の場合は｢Buzz｣を返す
数が3と5の倍数の場合は｢FizzBuzz｣を返す

これはそのままテストとして機能します｡
そして､このテストをパスする実装を書けば､FizzBuzzは完成します｡
つまり､テストを書くということは､設計していることと同義であると言えます｡

ベアプログラミング

プログラミング作法(Brian Kernighan著)という本に､こんなエピソードが載っています｡

自分のコードを誰かほかの人に説明して聞かせるのも効果的なテクニックだ｡
こうすると自分自身インバグが見えてくることが多い｡
場合によっては説明し始めた途端に気がついて｢あ､もういいや､変なところがわかったよ｡ごめん､ごめん｣などと言って照れくさい思いをすることもある｡
このテクニックは意外なほど有効だし､聞き手は別にプログラマでなくてもかまわない｡
ある大学の計算機センターのヘルプデスクのそばにはテディベアのぬいぐるみが常備されており､摩訶不思議なバグに悩む学生は､人間のスタッフに相談する前にぬいぐるみに向かって説明しなければならないことになっていた｡

有名な話なのでご存知のかたも多いと思いますが､簡単に説明すると

行き詰まっているときは､誰かに説明(相談)しよう｡
説明しようとすると､物事を整理するので思考がクリアになって問題の原因が見えてくるよ｡
でも一方的に話して｢もういいや｣は迷惑なので､まず最初にぬいぐるみを相手に整理してみてね!

というものです｡

これはテディベア効果だとか､ベアプログラミングと呼ばれているのですが､なんとなくTDDのテストに似ていると感じます｡

テストは高機能テディベア

実装したいプログラムの仕様を､テストとして書くことで頭の中が整理され､思考がクリアになり､よりきれいな設計でプログラムが書けるようになる｡
TDDのテストとは､テディベア効果､ベアプログラミングにおけるテディベアに相当するものだと思います｡
さらにこのテディベア､一度説明したことは覚えているし､そのプログラムが仕様から外れていれば､顔を真っ赤にして怒ってくれます｡
何回同じ質問をしても､どんなに酷使しても文句一つ言わないし､疲れもしません｡健気ですね

まとめ

｢TDDってなんか難しそうだなあ......｣

そう思っていましたが､今ではもっと気軽に実践するべきなのかなと感じています｡
もしプログラムの設計に悩んでいるのであれば､今すぐ実践してみてください｡
TDDのテストは､別に品質の保証をするためのものではないですし､最初は汚いテストになってもいいと思います｡
部分的書いてみるのもいいかもしれません｡
TDDは全然ハードルが高いものではないと思います｡
むしろ中級者になりきれない初級者くらいの人こそ1番恩恵を得られるのかな､と感じました｡

おすすめの勉強方法ですが

｢テスト駆動開発｣の1章と付録Cを読む
50分でわかるテスト駆動開発を観る
残りの章を読み進めながら本文中のコードを写経する

この流れで学習していけば､比較的理解しやすいのではないかなと思います｡

TDDは実際に手を動かしてみないとどういうものか理解し辛いと思います｡
是非一度テストを書きながら設計してみてください｡
きっとあなたの良き相棒として手助けしてくれるはずです｡

参考

テスト駆動開発
 50分でわかるテスト駆動開発
 プログラミング作法