TDDの目指すもの
http://blog.livedoor.jp/dankogai/archives/51024711.html
http://d.hatena.ne.jp/higayasuo/20080328
実際のところ、私はXPの本とかWebもろくに読んでないし、上二つの記事もろくすっぽに読んでないけれど、経験上感じたことを書いておきます。なので全て「思う」とつきます。知ったかです。現場の状況理解していません。
TDD*1で重要になってくるのは、ちゃんと、PCのテストツールがテストできるテストシナリオが書かれていること。誰が読んでも誤解無く理解できるテストシナリオを書く必要がある。そしてそのためには設計の時点で何をやったらどうなるのか、誰にでも分かるようでないといけない。TDDの目的は「設計の時点でテストを書くことで仕様を明確にする」であり、テストコードも本番のソースコードも適当でいいってのは話が違うような。
例えば「Aを入力してBをクリックしたら、正しく値が表示される」ってテストケースがあったとき、人間ならある程度解釈してテストしてみる。でもコンピュータ上で実行させようと思ったら、「正しい値が表示される」とは何ぞやと考えなければならない。
でも、本当はコンピュータ上じゃなくて人間でも「正しい値が表示される」なんて書かれたら、何確認するかわかんないよね。もっと具体的に「1と入力して確認ボタンを押したら、2と言う値が表示される」と書くとか、極端な話正しい結果の図でも書いてしまっていいのかもしれない。
もっとも丁寧に作りこめる時間ってあんまないよね？多分不具合を起こさないと納期を後ろにずらせないと思うんだ。だから最初の設計は適当にして、あたかも進捗報告で進んでるかの様に報告する。
ちなみに↓の奴はNUnitとかGUIテストすべきなんだろうけど、仕様がそもそもいい加減だし、仕様決めたらそのままコードになってる状態に近いのでぜんぜんかけてない。プロトタイプをそのまま製品にしてます。なんとも酷い話ですね。
