テストを最初に書くことのメリット
http://d.hatena.ne.jp/dann/20050810/p2
↑のid:dannさんのエントリ。大筋では同意なんだけど(TDDじゃないときはこんな作り方だし)、一点だけ。
Kent Beckもテストコードから書け!なんてことが言いたいわけでもないとは思いますしね。「試し書きしてからのほうが効率がよいです」なんて言っても本にはならないですから、一部は商売のための書いているところもあるんじゃないかななんて思ったりします。
そんなことはないですよー。ボクが思いつくだけでも、テストコードから書くこと(そしてテストが失敗することを確認すること)には以下のようなメリットがあります。
- 良いインターフェース
- 利用者側の視点から導出したインターフェースは良いインターフェースなことが多いです、理由は分からないけど
- だれか教えて
- 関数型プログラミング界隈でよく聞くフレーズな気がするけど、気のせいかも
- 利用者側の視点から導出したインターフェースは良いインターフェースなことが多いです、理由は分からないけど
- RED→GREENによる達成感
- REDからGREENになるときの「イェーイ!!」感
- やる気が出る
- あと、RED→GREEN→REFACTORのリズムが気持ちいい
- REDからGREENになるときの「イェーイ!!」感
- テストが正しく失敗することを確認
- 実装が正しくなければテストも正しく失敗する必要がある。それを確認するのも大事なテスト
- 最初にGREENにして後から実装をワザと壊してREDにするよりは、最初にREDにしてからGREENとした方が早いよね
- 分割統治&一歩一歩の成長
- ひとつのテストを通すことだけに集中できる
- 自然と分割統治&一歩一歩の成長(Pieacemeal Growth)な設計になる
他にもあるかも。
ちまみに。Kent Beckは
Never write a line of code without a failing test. -- Kent Beck
なんてことも言ってるみたい*1。