ゆっくり書いてる時間無いし、どうせテストするんだからバグはテストで見つければいい、と言って適当なコーディングばかりするプログラマーがたまにいます。
確かにテストはバグを見つけるためのものですが、品質の悪いプログラムのテストほど効率の悪いものはありません。
テスト⇒修正⇒テストの繰り返し回数が必要以上に多くなってしまいます。
どんなに優秀なプログラマーがどんなに慎重にコーディングしても、バグは絶対に発生します。
ましてや、適当にコーディングされたプログラムには、書いた本人が想像している以上のバグが潜んでいるはずです。
テストというのは、慎重に作ったけどどうしても発生してしまうバグを潰すためのもの、と思ってほしいです。
コーディングの時点で十割の品質は難しいでしょうが、プロならば、少なくとも八割ぐらいの品質でコーディングしてテストで十割にする、ぐらいの気持ちを持ってほしいです。
最初から適当に作られていたせいでソースが汚かった場合、修正箇所の特定が困難になったり修正ミスが多くなったりします。
そうなると、テストと修正を何度も繰り返す内に、更に新たなバグを作りこんで、またテストで見つけて･･･といった負のスパイラルに陥ります。
このようなスパイラルを経てようやく仕様通りに動くようになった頃には、元々汚かったソースがカオス状態になっていて迂闊に修正も仕様変更もできない、という状態になっていることと思います。
また、適当に作っていると、慎重に作っていれば気付いたであろう仕様や設計の不備を見落としがちです。
テストフェーズで仕様や設計の不備が見つかるのは遅すぎですし、大幅な手戻りになってしまいます。
遅くとも、作っている段階で気付きたいものです。
１回目のテストでバグを全て摘出し、それらを修正した後の２回目のテストはバグが無いことを確認する、というのが理想です。
もちろん、実際はこんなにうまくいかないでしょうが、テストフェーズでの修正は少ないに越したことはありません。
テストでバグを見つける前提でいい加減なコーディングをしていても、結局時間はかかるし品質は悪いしでいいことはありません。