C言語でOOPを使わないでプログラムを書く場合、テスト単位が関数になりやすいが、関数という単位はミクロすぎて殆ど意味がない。
関数単位でテストをしていても、関数の動作仕様に抜けがあったり間違いがあったりしたら全く意味がない。関数が望み通りの動作をしても、システムとして望みの動作にならないのだ。
http://d.hatena.ne.jp/methane/20060114
http://d.hatena.ne.jp/methane/20060116
この問題に対するソフトウェア工学の典型的な答えは、仕様を詳細に書き、レビューして、レビュー議事録を残せというモノだ。ソフトウェア工学者という奴の大半は、ソフトウェアの信頼性を高める手法を(1)ドキュメントを増やす、(2)ドキュメントをレビューする、(3)テスト網羅率を上げる、位しか知らないのだ。
この方法が糞の役にも立たない事はプログラマは判っている。
仕様書を関数単位に詳細に書いてレビューしたって、結局コードレビューするのと同じ効果しかないんだ。関数単位の仕様書を書いてる時間があれば、その時間をユニットテストとリファクタリングに充てた方がよっぽど品質が上がる。自然言語はソフトウェアを定義するのに適した言語じゃないから、自然言語で書いた詳細仕様なんてあいまいで検証の手段もない上にリファクタリングを妨げる害悪にしかならない。
テスト網羅率もそうだ。間違った認識で設計されたソフトを間違った認識のままテストしても間違いだし、間違った設計で実装されたコードが間違った設計通りに作られたことをテストしても間違いは直らない。そして、入れやすく見つけにくいバグは間違った認識と間違った設計によるものだ。テスト網羅率を80％から100％に上げている時間があったら、仕様書を読み、設計を見直し、コードを見直せ。網羅率100％のテストでは30％のバグしか見つけられないが、インスペクションでは90％のバグを見つけられる。プログラムテストの利点は自動化できることであり、自動化できない部分まで必死にテストしても品質が上がるわけではない。
