テストコードを書く意味

那須のKentBeckこと咳さん曰く

テストでは品質は上がらないですよ。テストはあくまでも品質をあげるきっかけ。品質をあげるのはプログラミングです。これは大昔からそう。

http://kakutani.com/20090213.html#p03

と言う言葉がありました。確かにそうだよな、と思ったのはいいですが、はてと思うこともありました。

じゃ、僕らはなんでテストコードを書くのだろう、

と。

以下、咳語録を自分なりに解釈して深く考えてみた軌跡です。

僕らはなぜテストコードを書くのか。それはCIにテストを組み込むことでデグレーションを起きたときに早期に気づくため、という答えもあるでしょう。が、僕が風呂に入ってぼーっとしていたら別の考えに気づきました。テストコードを書こうとすることにより、テスト対象のクラスの外側から渡ってくる値、入力と、返さないといけない値、出力を意識することで、テスト対象のクラスの質を上げるきっかけを増やしているのではないか?と思ったわけです。ソフトウェアで構築されたほとんどのシステムでは、フレームワークを用いていることが多い。いかんせん、フレームワークを使うとフレームワークから渡される値や返さないといけない値について無頓着になることが多々ある。JavaDoc等APIドキュメントにどうすべきか書かれている場合はまだ対応できますが、何もなかったらどうしますか？たいていの場合「気にしない」、と言う答えに辿り着くでしょう。でもそれって、フレームワークをブラックボックスとして中を見ない、という事なので、実はとっても不安なことだったりしませんか?自分の書いたコードが、フレームワークが想定している形かどうかどうやって検証するのでしょう?

フレームワークって想定されていない使われ方をすると、途端に意図したように動かなかったり、拡張できなかったりとひどい目に会うことが多くないですか？そういうことから逃れるために、テストコードを書こうとする姿勢が正しいコードを導く助けになってくれてるんじゃないのかなと思ったわけです。