今日は、独断と偏見による、単体テストの解釈なんてーものを書いてみたいと思います。というのも意見募集！単体テストってなんですか？というのを見たので。。
「単体テスト」というと、プログラム単体のテストのことをさします。
ので、「システム開発取引の共通フレーム SLCP-JCF」でいう、
・ソフトウェアユニットとデータベースの作成
（ソフトウエアユニット＝プログラムの基本単位、まあ、プログアムです）
の後に行われる、
・テスト手順とテストデータの作成、テストの実施
に相当するとおもってます。
（ＰＤＦでよければここにあります。そこの「エンジニアリングの視点」の「１．４ 開発サイクル」の「1.4.8 ソフトウェアコード作成及びテスト」)
で、たしか、上記の共通フレームでは、「プログラムの仕様書があって、その仕様書に対して、プログラムがあっているかどうかをテストする」という形になっていたと思います（記憶違いだったらすみません）。
上記の場合、詳細設計でプログラムの書き方が書いてあるので、それをもと（基準）に、テストする
＝＞結局、ホワイトボックステストの形になると思います。
で、問題は、仮に、プログラムについての仕様書が無かった場合（プログラムを書くための資料やインターフェースは決まっているが、プログラムをこう書きなさいという仕様書はない場合）。
この場合、共通フレームのように考えると、なにを基準にテストしていいかわからなくなります。そうすると、いったい、単体テストというのは、なにをやることなのか、ぼやけてくると思います。
・インターフェースに入出力するものだけあっていれば良い？
→でも、これって、インターフェースの結合テスト（ＩＴ１って言ってるところもあるかも？）
とどう違うの？
・ホワイトボックステストで、網羅しているかどうかを。。。
→でも、それって、そもそも、仕様を勘違いしてたらおしまいだしなあ。。。
（仕様書を書いてないんだから、だれも確認できないわけで。。。）
つーことで、プログラムの仕様書が事前に出来ていない場合、なにをテストしたらいいのだか、はっきりしなくなってしまうとウィリアムのいたずらは思ってます。
なので、下請けフリーのＳＥのウィリアムのいたずらは、「単体テスト、どんな風にやりますか？」とききます。実際、やってること、まちまちなんで。
問題は、プログラムの仕様書、詳細設計書をつくるか？ということです。
COBOLの時代は、あった記憶があります
（たぶん、共通フレームもその時代のことの話でしょう）
で、最近、Webで、たとえば、Actionの中をこう書いてくださいという仕様書は。。。
ごそうぞうに、おまかせするぞ！
