InfoQの記事です。
Kent Beck氏、ごく短期のプロジェクトではテストを省略することを提案
うーん、リファクタリングだけの為にテストコードを書くとしている人は
それでもいいのかもしれませんが、個人的には保守し続ける為にテストが必要だと思っています。
最終的にテストを実施していれば良いとは思いますが・・・。
簡単に修正できるのだが、テストを書くのに数時間かかると見積もった問題だ。この場合、彼は修正だけをして、出荷していたそうだ。
その時は良いかもしれないけど、テストを書かないことでデグレに気づきにくくなるんじゃないかなぁ。
「簡単に修正できる」と判断をする人次第かもしれないけど、それを修正した時の影響を甘く見積もってた時とか
出荷した後に発覚するから慎重にしなきゃいけないのでは？と思います。
スキルや文化の差かもしれませんが、本番リリースしないモック的なもの以外はできるだけテストした方が良いのでは？
僕がJUnitを書く時ってのは、そもそも見たす仕様をメソッドレベルで分割して、そこから書くからスピードは遅いです。
「すぐ動くもの」を作れ、というのには合っていないでしょう。
でも、作ろうとするものが一秒も早くリリースしないと意味がなくなるものでない限り
しっかり足場を固めて少しずつやった方が最終的な工数が少なく済むんじゃないかなーと思います。*1
ウサギとカメな感じがしてきた。
*1:もちろん、技術調査とかテンプレート的なものはとっとと作った上での話です
