不安をテストに

昨日書いたようなTDDの話を初めて聞いた時に個人的に特に腑に落ちたのが「不安をテストに」

TDDを始めてみたはいいものの、何に対してどこまでテストを書いたらいいのか分からないという人は多いんじゃないかと思う。
その分かりやすい指標として「不安」を用いる。

「不安」なんて主観的であいまいだと思うかもしれないが、TDDはプログラマが自分のためにやることなのでいいのである。（TDDは品質は担保するものではないということを忘れてはならない）
そもそも自分の経験やスキルをもとに判断して普通にコードを書いていくのと本質的な部分では何も変わらない。
チームならペアプロやコードレビューでフォローもできることだし。

というわけで「不安」を感じなければそれ以上テストを書く必要はない。
だが「不安」を感じたらテストをいつでも追加できるということが力強い。
おかげで「不安」を感じなければ心置きなく次のことに進むことができる。

またTDDをやっていてもバグは発生するが、バグが出たらそれに対してテストを書いて（Redにして）から修正（Greenに）する。
それによってバグの再発する「不安」をテストによって封じ込めることができる。
バグが出てからテストを書いても手遅れにはならないということだ。

なんかすごい気が楽じゃないですか。

ところで

まったく不安を抱かない人はテストを書かなくていいのか？
回答はYES。
ただし例外的なケース。

例えば6段ネストしたループを脳内から一筆書きでコードに書き下せるような人（和田さん曰くきしださん）にはTDDはいらない。
そういう人からするとTDDはめんどくさいことにしか思えない。
要するに天才タイプにはTDDは不要。

ただしチームで仕事する場合は別で、コミュニケーションおよびソースコード共有の手段としてTDDは有効だし天才タイプの人にもメリットがある。