テストファーストとひらめく人々

Matzにっき(2005-07-09) 「なぜテスト駆動が身につかないか」

「なにかを作りたい」と思った時、テストファーストなら「そのなにかをテストによって表現する」わけだが、私はその作りたいものがコードとして脳裏に浮かぶのだ。そこでテストを書いていると、その浮かんできたコードがどこかへ逃げてしまうような気がする。脳裏に浮かんだコードが消えてしまわないうちに、素早くタイプして書き留めてしまわないといけない。

自分もそんな感じはけっこうある。

仕様を見たりこういうものを作ろうと思ったら、なんとなくプログラムが連携している様子が浮かんできて、それを忘れないうちに打ち込む。メモするにしても丸とか四角とか矢印ぐらいで、UMLでもなんでもない。そして、作りながら細部を決定して完成させる感じ。動作チェックを手でやるのがめんどくさい場合は仕方なく自動テストを作る。

http://blog.netbeans.jp/roller/page/kishida/20050512#12356_12365_12394_12426_12467 「いきなりコーディングが行われるのは設計やモデルが必要ないから」

設計とかなしにコード書いてるところっていうのは、設計が必要ないとかコード書いて試行錯誤が必要だから設計が行われてないんじゃないかと。

情報伝達のために「設計」が必要という話もあると思うんですけど、それならその「設計」の代わりに実装の「その部分」を手軽に書ける仕組みがあるほうがありがたいです。

http://blog.netbeans.jp/roller/page/kishida/20050313#12486_12473_12488_12375_12390 「テストしてない=品質を考えてない？」

むしろ、品質をちゃんと考えて、バグがでないように努力してやってるから、テストなしでやれてるわけで。

プログラムを作っている以上テストを全くしていないということはなくて、Excelで立派なシートを作ってそれに記入していくような「テスト」はやっていないということだと思う。

ただ、こういうテストシートはあんまりバカには出来なくて、実際に自分で完璧だと思っていても、テストシートによるチェックでたまにバグが発見されることがある。特に自分の手を離れたものがそのままプロダクションリリースになってしまうケースが多いので、リリースするときには必ず行うようにしている。

ちなみに、テスト項目はよくある境界値とかではなくて過去に発見されたバグから取ってきている。報告されたバグの境界値は、いつも自分のプログラムの想定外なことが多い。また、そこから得られる傾向としては、当初の設計どおりの部分ではバグはあんまり出てこなくて、当初の設計を拡張するような修正からたくさんバグが出て来ている。本当は設計から変えたいのだけど、そういう時間が無いという悲しい現実を反映している。結局は作り直したほうが最終的にかかるコストは低いのだけど、営業的には対応期間に穴をあけるわけにはいかないし、このジレンマが毎回難しい。

テストは積極的に行えば開発プロセスとしても使えるし、最初から全体の開発プロセスに組みこめれれば、プロジェクトの可視化が実現できたり、バグを早期に発見することで納期を早めたり全体的なコストを下げる効果もある。また、何をテストするべきか、誰がやるのか、リリース時期の判断、テストに必要な具体的ノウハウなど、テストはなかなか深い。

やっぱり、ここは福岡でテストイベントをやってもらうしか・・・。